ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-28T11:19:14Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4659rootkeysentinel test is unstable2024-03-28T11:19:14ZPetr Špačekpspacek@isc.orgrootkeysentinel test is unstableVersion: main branch
Test: bin/tests/system/rootkeysentinel
This test fails repeatedly and needs investigation. It has failed 3/14 runs in the last two weeks.
Last failed run: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4166955Version: main branch
Test: bin/tests/system/rootkeysentinel
This test fails repeatedly and needs investigation. It has failed 3/14 runs in the last two weeks.
Last failed run: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4166955https://gitlab.isc.org/isc-projects/stork/-/issues/1350Make RADIUS-related sytem tests compatible with Kea 2.52024-03-28T10:17:29ZSlawek FigielMake RADIUS-related sytem tests compatible with Kea 2.5Upgrading Kea in system tests to the 2.5 version caused a system test failure that involved RADIUS. Kea team is working on RADIUS changes which apparently has changed in 2.5.
It blocks us from upgrading Kea in system tests and writing t...Upgrading Kea in system tests to the 2.5 version caused a system test failure that involved RADIUS. Kea team is working on RADIUS changes which apparently has changed in 2.5.
It blocks us from upgrading Kea in system tests and writing the system tests for the hub-and-spoke feature.https://gitlab.isc.org/isc-projects/stork/-/issues/1349HA panel should use Stork-style machine naming2024-03-28T10:07:06ZSlawek FigielHA panel should use Stork-style machine namingPlease use the machine name in the application identifier. It should be: `kea@agent-kea-ha1` and `kea@agent-kea-ha3` instead of `Kea@127.0.0.1`. We usually use this convention in Stork.
Current:
![image](/uploads/7e083489c97d5ff8d60d4...Please use the machine name in the application identifier. It should be: `kea@agent-kea-ha1` and `kea@agent-kea-ha3` instead of `Kea@127.0.0.1`. We usually use this convention in Stork.
Current:
![image](/uploads/7e083489c97d5ff8d60d469699eb380a/image.png)
After #1274 merge:
![image](/uploads/7a22035e53f32a1544235987e84cad8f/image.png)https://gitlab.isc.org/isc-projects/kea/-/issues/3323Fix undefined behaviors reported by UBSan2024-03-28T09:49:32ZAndrei Pavelandrei@isc.orgFix undefined behaviors reported by UBSanThree types of UBs are reported at https://reports.kea.isc.org/tests_status/ut-ubsan.html. I think all of them are worth fixing.
- `runtime error: constructor call on misaligned address * for type '*', which requires * byte alignment`
-...Three types of UBs are reported at https://reports.kea.isc.org/tests_status/ut-ubsan.html. I think all of them are worth fixing.
- `runtime error: constructor call on misaligned address * for type '*', which requires * byte alignment`
- `runtime error: load of value *, which is not a valid value for type '*'`
- `runtime error: member call on misaligned address * for type '*', which requires * byte alignment`https://gitlab.isc.org/isc-projects/bind9/-/issues/4658Release Checklist for BIND 9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.232024-03-28T10:11:38ZPetr Špačekpspacek@isc.orgRelease Checklist for BIND 9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23## Release Schedule
**Code Freeze:** Tuesday, 2 April 2024
**Tagging Deadline:** Friday, 5 April 2024
**Public Release:** Wednesday, 17 April 2024
## Documentation Review Links
**Closed issues assigned to the milestone without a r...## Release Schedule
**Code Freeze:** Tuesday, 2 April 2024
**Tagging Deadline:** Friday, 5 April 2024
**Public Release:** Wednesday, 17 April 2024
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.16.50](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
- [9.16.50-S1](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16-S)
- [9.18.26](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.18.26-S1](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18-S)
- [9.19.23](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%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.50](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16)
- [9.16.50-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16-sub)
- [9.18.26](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18)
- [9.18.26-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18-sub)
- [9.19.23](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=main)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.16.50](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16)
- [9.16.50-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16-sub)
- [9.18.26](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18)
- [9.18.26-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18-sub)
- [9.19.23](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=April+2024+%289.16.50%2C+9.16.50-S1%2C+9.18.26%2C+9.18.26-S1%2C+9.19.23%29&label_name%5B%5D=No+CHANGES&target_branch=main)
## Release Checklist
### Before the Code Freeze
- [ ] ***(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).
- [ ] ***(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.
- [ ] ***(QA)*** Check charts from `shotgun:*` jobs in the scheduled pipelines to verify there is no unexplained performance drop for any protocol.
- [ ] ***(QA)*** Check [Perflab](https://perflab.isc.org/) to ensure there has been no unexplained drop in performance for the versions being released.
- [ ] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [ ] ***(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).
- [ ] ***(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.
- [ ] ***(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
- [ ] ***(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.
- [ ] ***(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)
- [ ] ***(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)
- [ ] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only). [Example](https://gitlab.isc.org/isc-private/bind9/-/commit/0f03d5737bcbdaa1bf713c6db1887b14938c3421)
- [ ] ***(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)).
- [ ] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [ ] ***(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)
- [ ] ***(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)
- [ ] ***(QA)*** Check that the formatting is correct for the HTML version of release notes.
- [ ] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [ ] ***(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.
- [ ] ***(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)
- [ ] ***(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 maintained branch.
- [ ] ***(QA)*** Rebase the Subscription Edition branches (including recent release prep commits) on top of the open source branches with updated version strings.
- [ ] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [ ] ***(QA)*** Request signatures for the tarballs, providing their location and checksums. Ask [signers on Mattermost](https://mattermost.isc.org/isc/channels/bind-9-qa).
- [ ] ***(Signers)*** Ensure that the contents of tarballs and tags are identical.
- [ ] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [ ] ***(QA)*** Verify tarball signatures and check tarball checksums again: Run `publish_bind.sh` on repo.isc.org to pre-publish.
- [ ] ***(QA)*** Prepare the `patches/` subdirectory for each security release (if applicable).
- [ ] ***(QA)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [ ] ***(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)
- [ ] ***(Marketing)*** Prepare and send out ASN emails (as outlined in the CVE checklist; if applicable).
### On the Day of Public Release
- [ ] ***(QA)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [ ] ***(QA)*** Place tarballs in public location on FTP site.
- [ ] ***(QA)*** Inform Marketing of the release, providing FTP links for the published tarballs.
- [ ] ***(QA)*** Use the [Printing Press project](https://gitlab.isc.org/isc-private/printing-press/-/wikis/home#adding-new-documents) to prepare a release announcement email.
- [ ] ***(Marketing)*** Publish links to downloads on ISC website. [Example](https://gitlab.isc.org/website/theme-staging-site/-/commit/1ac7b30b73cb03228df4cd5651fa4e774ac35625)
- [ ] ***(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.)
- [ ] ***(Marketing)*** Update the Current Software Versions document in the SF portal if any stable versions were released.
- [ ] ***(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)).
- [ ] ***(Marketing)*** Announce release on social media sites.
- [ ] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [ ] ***(Support)*** Add the new releases to the [vulnerability matrix in the Knowledge Base](https://kb.isc.org/docs/aa-00913).
- [ ] ***(Support)*** Update tickets in case of waiting support customers.
- [ ] ***(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)
- [ ] ***(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
- [ ] ***(SwEng)*** Build Debian/Ubuntu packages.
- [ ] ***(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)
- [ ] ***(QA)*** Ensure all new tags are annotated and signed. `git show --show-signature v9.19.12`
- [ ] ***(QA)*** Push tags for the published releases to the public repository.
- [ ] ***(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.
- [ ] ***(QA)*** Ensure `allow_failure: true` is removed from the `cross-version-config-tests` job if it was set during the current release cycle.
- [ ] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [ ] ***(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].
- [ ] ***(QA)*** Update QA tools used in GitLab CI (e.g. Black, PyLint, Sphinx) by modifying the relevant [`Dockerfile`](https://gitlab.isc.org/isc-projects/images/-/merge_requests/228/diffs).
- [ ] ***(QA)*** Run a pipeline to rebuild all [images](https://gitlab.isc.org/isc-projects/images) used in GitLab CI.
- [ ] ***(QA)*** Update [`metadata.json`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/metadata.json) with the upcoming release information.
[^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.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/1348Remove stork-repo tag from .gitlab-ci.yaml2024-03-27T16:57:15ZSlawek FigielRemove stork-repo tag from .gitlab-ci.yamlThe `upload_to_repo` CI task is not working as described [on MM QA channel](https://mattermost.isc.org/isc/pl/eoq3yfamnbfz7n6tfaewdmc6mh).
We got this error:
> This job is stuck because of one of the following problems. There are no ac...The `upload_to_repo` CI task is not working as described [on MM QA channel](https://mattermost.isc.org/isc/pl/eoq3yfamnbfz7n6tfaewdmc6mh).
We got this error:
> This job is stuck because of one of the following problems. There are no active runners online, no runners for the protected branch, or no
runners that match all of the job's tags:
Its tags defined in the .gitlab-ci.yml file are:
- linux
- aws
- runner-manager
- amd64
- stork-repo
I checked the Stork repository settings and it seems there is no runner that matches the requirements.
The `aws` tag is missing in all runners that have the stork-repo tag.
### Proposed solution:
* remove `stork-repo` tag from `upload_to_repo` job in .gitlab-ci.yml.
* remove `-4` (which enforces IPv4 connection) from `ssh-keyscan -4 repo.isc.org >> ~/.ssh/known_hosts`https://gitlab.isc.org/isc-projects/stork/-/issues/13471.15.1 Clean up2024-03-28T09:04:35ZMarcin Godzina1.15.1 Clean upThings to do after 1.15.1 release:
- [ ] Move private code to public repository
- [ ] Mark [Tag](https://gitlab.isc.org/isc-projects/stork/-/tags) and [Release](https://gitlab.isc.org/isc-projects/stork/-/releases) in Repository
- [ ] R...Things to do after 1.15.1 release:
- [ ] Move private code to public repository
- [ ] Mark [Tag](https://gitlab.isc.org/isc-projects/stork/-/tags) and [Release](https://gitlab.isc.org/isc-projects/stork/-/releases) in Repository
- [ ] Rebuild Read The Docks (It can not pull from a private repository.)
- [ ] Fix `upload_to_repo` and `upload_to_repo_hooks` jobs/runners problem https://gitlab.isc.org/isc-projects/stork/-/issues/1348 https://gitlab.isc.org/isc-projects/stork/-/issues/13121.16https://gitlab.isc.org/isc-projects/stork/-/issues/1342Agent installation script doesn't work with stork configured for https2024-03-27T10:50:22Zjerry bonnerAgent installation script doesn't work with stork configured for https---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/...---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to
security-office(at)isc(dot)org.
**Describe the bug**
Stork 1.15.0 configured with https. Agent installation script from GUI details :
wget https://x.x.x.x:8080/stork-install-agent.sh
However, stork-install-agent.sh is configured to download package via :
curl -o /tmp/isc-stork-agent.deb "x.x.x.x:8080/assets/pkgs/isc-stork-agent_1.15.0.240205220739_amd64.deb"
Note that "https://" is not specified.
Resulting in a downloaded file that contains:
Client sent an HTTP request to an HTTPS server.
**To Reproduce**
Steps to reproduce the behavior:
1. Install Stork 1.15.0 and configure with https
2. Execute provided agent installation from GUI
3. Script fails because isc stork agent package is attempted to be downloaded via http, but stork is configured with https
**Expected behavior**
Stork should code agent installation script to download asset package via https, if STORK_REST_TLS_CERTIFICATE is configured.
**Environment:**
- Stork: 1.15.0
- OS: Ubuntu 20.04https://gitlab.isc.org/isc-projects/kea/-/issues/3315hooks shouls use their own IOService instance and register it with the main I...2024-03-28T13:45:52ZRazvan Becheriuhooks shouls use their own IOService instance and register it with the main IOServicerelated to https://gitlab.isc.org/isc-projects/kea/-/issues/3308
to properly load and run IOService poll so that configuration errors are detected before configuration is applied and to unload hooks and safely call all close callbacks, ...related to https://gitlab.isc.org/isc-projects/kea/-/issues/3308
to properly load and run IOService poll so that configuration errors are detected before configuration is applied and to unload hooks and safely call all close callbacks, a "local" IOService instance should be used by each hook. this guarantees that there can be no handlers referencing objects created in the hook that are called after hook unload.
hooks that use main io service:
premium:
* gss_tsig
* forensic_log
* lease_query
* ping_check
* radius
core:
* high_availability
* mysql_cb
* pbsql_cb
* run_script
all hooks requiring IOService should do the following:
```plaintext
int unload() {
if (getMainIOService()) {
getMainIOService()->unregisterExternalIOService(getIOService());
}
getIOService()->stop();
getIOService()->restart();
try {
getIOService()->poll();
} catch (...) {
}
...
}
int dhcp4_srv_configured(CalloutHandle& handle) {
handle.getArgument("io_context", getMainIOService());
if (!getMainIOService()) {
// Should not happen!
handle.setStatus(isc::hooks::CalloutHandle::NEXT_STEP_DROP);
const string error("Error: io_context is null");
handle.setArgument("error", error);
return (1);
}
...
getMainIOService()->registerExternalIOService(getIOService());
...
}
int dhcp6_srv_configured(CalloutHandle& handle) {
handle.getArgument("io_context", getMainIOService());
if (!getMainIOService()) {
// Should not happen!
handle.setStatus(isc::hooks::CalloutHandle::NEXT_STEP_DROP);
const string error("Error: io_context is null");
handle.setArgument("error", error);
return (1);
}
...
getMainIOService()->registerExternalIOService(getIOService());
...
}
void
IOService::registerExternalIOService(IOServicePtr io_service) {
external_io_services_.push_back(io_service);
}
void
IOService::unregisterExternalIOService(IOServicePtr io_service) {
auto it = std::find(external_io_services_.begin(), external_io_services_.end(), io_service);
if (it != external_io_services_.end()) {
external_io_services_.erase(it);
}
}
void
IOService::pollExternalIO() {
for (auto& io_service : external_io_services_) {
io_service->poll();
}
}
```
built on top of #3281
I confirm it fixes the crash in #3308https://gitlab.isc.org/isc-projects/kea/-/issues/3314RBAC: Omitting configuration option results in logged error2024-03-26T21:44:52ZDarren AnkneyRBAC: Omitting configuration option results in logged errorThe configuration directive `"response-filters"` seems to be de facto required whereas the ARM seems to imply that this parameter should be optional as it shows examples where the parameter is not present (see the extensive example). It...The configuration directive `"response-filters"` seems to be de facto required whereas the ARM seems to imply that this parameter should be optional as it shows examples where the parameter is not present (see the extensive example). It doesn't actually say whether the parameter is required or optional, however.
Omitting the directive causes this error:
```
[kea-ctrl-agent.callouts/401411.129873316435840] HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook response registered by library with index 1 (callout address 0x761e7c475880): unable to find callout context associated with the current library index (1) (callout duration: 0.047 ms)
```
The error does not seem to cause any harm as the operations still seem to be performed. This can fill up the logs though if there is a lot of API access (such as in the case of Stork).
Adding the directive to the roles configuration(s) removes the error.
[SF1816](https://isc.lightning.force.com/lightning/r/Case/500S6000007Ho67IAC/view)Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3312D2 can enounters write errors sending to DNS2024-03-27T11:53:32ZThomas MarkwalderD2 can enounters write errors sending to DNSDuring tests for #3295 which used a single bind9 DNS server I discoverd that under enough load for a long enough period of time D2 begins to encounter errors writing to the DNS server:
2024-03-26 15:00:22.965 ERROR [kea-dhcp-ddns.asiodn...During tests for #3295 which used a single bind9 DNS server I discoverd that under enough load for a long enough period of time D2 begins to encounter errors writing to the DNS server:
2024-03-26 15:00:22.965 ERROR [kea-dhcp-ddns.asiodns/4711.140284993357696] ASIODNS_SEND_DATA error 101 sending data using UDP to 175.16.1.1(53)
Error code 101 is Network Unreachable.
When this occurs, excuting "nsupdate" from the command line of D2's host produces similar result:
```
tmark@ubuserver:kea $ nsupdate -v $HOME/n.txt
; Communication with 175.16.1.1#53 failed: operation canceled
could not reach any name server
```
I do not, at this time, know the root cause of these write failures. Excuting
an nsupdate from another VM is successful.
In addition to the write failures themselves, I believe there is an error in how IOFetch handles these errors. It appears that the fetch is allowed to proceed to executing a read after the send has failed, rather that calling IOFetch::stop() as is done for read TIME_OUTs. There seems little point executing a read that will only timeout. This has the affect of causing D2 to do 3 send(fail)/read(timeout) cycles.
Bottom line is there are two questions:
1. What causes the Network Unreachable errors?
2. Should IOFetch() fail on send failures (perhaps by callng stop()) rather than proceed to read after failed send?
The testing referred to above was done with:
1. Centos 7 VM running perfdhcp:
perfdhcp -4 -r 20 -R 10000000 -p 600 -l enp0s10 -W 5000000
2. Centos 7 VM running BIND9 9.11.2:
```rndc -c /opt/bind9/bind-9.11.2/local/servers/42620/rndc.conf status
version: BIND 9.11.2 <id:0a2b929>
running on cthird: Linux x86_64 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017
boot time: Tue, 26 Mar 2024 13:00:27 GMT
last configured: Tue, 26 Mar 2024 13:00:27 GMT
configuration file: /opt/bind9/bind-9.11.2/local/servers/42620/named.conf
CPUs found: 4
worker threads: 4
UDP listeners per interface: 3
number of zones: 6 (0 automatic)
debug level: 100
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/900/1000
tcp clients: 0/150
server is up and running
```lsb_release -a
3. Ubuntu VM 22.02 running kea-dhcp4 and kea-dhcp-ddns, configs attached:
[kea-d2.conf](/uploads/1ec60a23a57c33f03ee4621d6a15c048/kea-d2.conf)
[kea-ddns4.conf](/uploads/7300d3f06194bd7b2310daaed278d722/kea-ddns4.conf)
```https://gitlab.isc.org/isc-projects/stork/-/issues/1341Add a reference from the Stork ARM to the KB on how to generate the certifica...2024-03-28T10:29:47ZMarcin SiodelskiAdd a reference from the Stork ARM to the KB on how to generate the certificates?We have created KB on how to generate and import the certificates to Stork. I wonder if we maybe need to give a link from the Stork ARM to this article?We have created KB on how to generate and import the certificates to Stork. I wonder if we maybe need to give a link from the Stork ARM to this article?1.16https://gitlab.isc.org/isc-projects/kea/-/issues/3311kea-dhcp4 and 6: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be remov...2024-03-25T21:07:26ZHarry G. Coinkea-dhcp4 and 6: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.On both dhcp 4 and 6, over many upgrades in the past month this warning remains:
kea-dhcp4: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
Likely on the next major db client upgrade, mysql and maria...On both dhcp 4 and 6, over many upgrades in the past month this warning remains:
kea-dhcp4: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
Likely on the next major db client upgrade, mysql and mariadb will no longer answer kea requests.
Probably worth fixing 'real soon now', before conditions of time pressure arise from total failure.https://gitlab.isc.org/isc-projects/kea/-/issues/3310Documentation should include more examples with IPv6 addresses in URLs2024-03-25T12:34:33ZFrancis DupontDocumentation should include more examples with IPv6 addresses in URLsThe reason is the syntax is no so trivial... I suggest to add at least one in ARM (hooks-ha.rst) and in kea6 examples.The reason is the syntax is no so trivial... I suggest to add at least one in ARM (hooks-ha.rst) and in kea6 examples.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1337reservations without an IP do not show up in host reservations2024-03-27T18:24:20Zmichael balesreservations without an IP do not show up in host reservations---
name: reservations without an IP do not show up in host reservations
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. ...---
name: reservations without an IP do not show up in host reservations
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to
security-office(at)isc(dot)org.
**Describe the bug**
Stork allows the creation of reservations with just a mac address and client class but the reservation does not show up in the host reservation list.
**To Reproduce**
Steps to reproduce the behavior:
1. Install BIND9, Kea, Stork (which versions?) and run them with the following configs: '...'
2. I do the following: ...
3. A device in my network does the following: ...
4. Kea/BIND9 server does the following: ...
5. Stork does the following: ...
**Expected behavior**
A clear and concise description of what you expected to happen:
The Stork is supposed to report/do A, but didn't or did B instead.
**Environment:**
- Kea version:
2.5.6
isc20240226130228 deb
linked with:
log4cplus 2.0.5
OpenSSL 3.0.2 15 Mar 2022
database:
MySQL backend 21.0, library 8.0.36
PostgreSQL backend 20.0, library 140011
Memfile backend 3.0
- Stork: 1.15.0
- OS: Ubuntu 22.04.4 LTS x86_64
- Kea: "hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_pgsql_cb.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_host_cmds.so"
}
**Additional Information**
logs from adding the reservation:
```
082 17:40:10.417 kea-dhcp4.commands COMMAND_SOCKET_CONNECTION_OPENED Opened socket 37 for incoming command connection
082 17:40:10.417 kea-dhcp4.commands COMMAND_SOCKET_READ Received 212 bytes over command socket 37
082 17:40:10.418 kea-dhcp4.commands COMMAND_RECEIVED Received command 'reservation-add'
082 17:40:10.418 kea-dhcp4.callouts HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_add
082 17:40:10.418 kea-dhcp4.host-cmds-hooks HOST_CMDS_RESERV_ADD reservation-add command called (parameters: { "reservation": { "client-classes": [ "known-clients-106" ], "hw-address": "C03EBA93B18D", "subnet-id": 3 } })
082 17:40:10.418 kea-dhcp4.database DATABASE_PGSQL_START_TRANSACTION starting a new PostgreSQL transaction
082 17:40:10.422 kea-dhcp4.database DATABASE_PGSQL_COMMIT committing to PostgreSQL database
082 17:40:10.423 kea-dhcp4.host-cmds-hooks HOST_CMDS_RESERV_ADD_SUCCESS reservation-add command success (parameters: { "reservation": { "client-classes": [ "known-clients-106" ], "hw-address": "C03EBA93B18D", "subnet-id": 3 } })
082 17:40:10.423 kea-dhcp4.callouts HOOKS_CALLOUT_CALLED hooks library with index 4 has called a callout on hook $reservation_add that has address 0x7ff4efd4e900 (callout duration: 5.567 ms)
082 17:40:10.423 kea-dhcp4.callouts HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_add (total callouts duration: 5.567 ms)
082 17:40:10.423 kea-dhcp4.commands COMMAND_SOCKET_WRITE Sent response of 38 bytes (0 bytes left to send) over command socket 37
082 17:40:10.423 kea-dhcp4.commands COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 37 for existing command connection
```
after the reservation is added the reservation list in stork does not show the mac address or hostname
**Describe the solution you'd like*
Reservations without an assigned IP address should show the hostname and mac address in the reservation list.
**Additional context**
We use small DHCP pools of 20 or so addresses so handle mobile devices that are occasionally connected to the network. We managed this with isc-dhcpd previously by using global reservations with just a mac address. It looks like in isc-kea a mac address and a resource are required and my understanding is that a client class counts as a resource so the reservation should be valid. Instead of global reservations we are now using per subnet reservations.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any
permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs?
Yes this is a possibility
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code?
Yes i am willing to participate in development.
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them.1.17https://gitlab.isc.org/isc-projects/kea/-/issues/3305config test should also run poll after loading hooks2024-03-22T14:46:13ZRazvan Becheriuconfig test should also run poll after loading hooksthe fix in https://gitlab.isc.org/isc-projects/kea/-/issues/2692 does not consider testing the configuration when using -T as command line parameterthe fix in https://gitlab.isc.org/isc-projects/kea/-/issues/2692 does not consider testing the configuration when using -T as command line parameterhttps://gitlab.isc.org/isc-projects/stork/-/issues/1336Stork-Server is confused by multiple Kea DHCP versions installed2024-03-26T11:25:44ZCarsten StrotmannStork-Server is confused by multiple Kea DHCP versions installed---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
Stork-Server (or Stork-Agent) is confused by multiple Kea-DHCP versions installed on the same machine and displays inconsistent version number.
On...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
Stork-Server (or Stork-Agent) is confused by multiple Kea-DHCP versions installed on the same machine and displays inconsistent version number.
On my (testing) system, I have the OS delivered Kea-DHCP (version 2.4.1 from Fedora 39) as well as a Kea-DHCP version (2.5.6 installed from source). The Version 2.4.1 is "in path" (/usr/bin:/usr/sbin) but not running, whereas 2.5.6 is not "in path" (/opt/kea/sbin), but "is" running.
Stork does display both versions numbers:
![Stork-Kea-Version-Number02.png](/uploads/9b5291671228bdb67c5c6c799278fe59/Stork-Kea-Version-Number02.png)
![Stork-Kea-Version-Number01.png](/uploads/ad42cf27202a4f5a91463da2ef91a88b/Stork-Kea-Version-Number01.png)
**To Reproduce** Steps to reproduce the behavior:
1. two different versions of Kea DHCP, Stork Agent and Stork Server
2. check the Kea Version numbers in the Stork Web-UI
**Expected behavior**
Show the running Kea-DHCP version number all the time.https://gitlab.isc.org/isc-projects/bind9/-/issues/4652query.c:10467: INSIST(namereln == dns_namereln_subdomain) failed, back trace2024-03-27T14:02:05ZOndřej Surýquery.c:10467: INSIST(namereln == dns_namereln_subdomain) failed, back trace### Summary
Server crash caused by external UDP queries.
### BIND versions affected
```
BIND 9.19.23-dev (Development Release) <id:b1ebd49>
running on Linux x86_64 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)
bui...### Summary
Server crash caused by external UDP queries.
### BIND versions affected
```
BIND 9.19.23-dev (Development Release) <id:b1ebd49>
running on Linux x86_64 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)
built by make with 'CC=' 'LD=' 'CFLAGS=-O0 -ggdb -Wno-deprecated-declarations -fno-omit-frame-pointer -fno-optimize-sibling-calls -mtune=alderlake -DISC_MEM_USE_INTERNAL_MALLOC=0 -DISC_MEM_TRACKLINES=1 -DISC_TRACK_PTHREADS_OBJECTS' 'LDFLAGS=' '--enable-developer' '--enable-warn-error' '--with-openssl' '--with-zlib' '--with-libxml2' '--with-json-c' '--with-readline' '--with-libidn2' '--disable-dnstap' '--with-libtool' '--without-make-clean'
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 liburcu version: 0.15.0-pre
compiled with jemalloc version: 5.3.0
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
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: /dev/null
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
geoip-directory: /usr/share/GeoIP
```
9.18 is not affected with the same attack pattern.
### Preconditions and assumptions
None.
### Attacker's abilities
Ability to send queries to the server.
### Impact
Server crashes with assertion failure.
### Steps to reproduce
1. Run `bin/named/named -g -c /dev/null -p 12345`
2. Run 2x `dnsperf -d queryfile-example-10million-201202 -p 12345 -s 10.10.10.20 -t 20 -S 1 -e -D -b 16000`
3. Wait
### What is the current *bug* behavior?
Server crashes.
### What is the expected *correct* behavior?
Server doesn't crash.
### Relevant logs
```
21-Mar-2024 14:58:36.219 REFUSED unexpected RCODE resolving 'www.pressrepublicanevents.com/A/IN': 64.40.12.250#53
21-Mar-2024 14:58:36.227 REFUSED unexpected RCODE resolving '3.gvt0.com/A/IN': 2001:4860:4802:32::a#53
21-Mar-2024 14:58:36.259 DNS format error from 89.108.89.143#53 resolving 4kings.ru/MX for 10.10.10.106#36493: empty question section
21-Mar-2024 14:58:36.283 REFUSED unexpected RCODE resolving '3.gvt0.com/A/IN': 2001:4860:4802:34::a#53
21-Mar-2024 14:58:36.311 REFUSED unexpected RCODE resolving 'bioquimicasrl.com/A/IN': 209.244.0.3#53
21-Mar-2024 14:58:36.323 SERVFAIL unexpected RCODE resolving 'www.tom-morrow-land.com/AAAA/IN': 1.1.1.1#53
21-Mar-2024 14:58:36.327 REFUSED unexpected RCODE resolving '3.gvt0.com/A/IN': 216.239.36.10#53
21-Mar-2024 14:58:36.331 REFUSED unexpected RCODE resolving 'www.pressrepublicanevents.com/A/IN': 64.40.12.251#53
21-Mar-2024 14:58:36.331 query client=0x7fa869baf000 thread=0x7fa86cefd680(www.pressrepublicanevents.com/A): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.331 query client=0x7fa83b1a3400 thread=0x7fa85b3fe680(www.pressrepublicanevents.com/A): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.339 success resolving 'www.angrybirdsfree.net/AAAA' after disabling qname minimization due to 'ncache nxdomain'
21-Mar-2024 14:58:36.339 query client=0x7fa83b221400 thread=0x7fa85b3fe680(www.tom-morrow-land.com/AAAA): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.339 query client=0x7fa869a3e400 thread=0x7fa86cefd680(www.tom-morrow-land.com/AAAA): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.359 success resolving 'e1.mc658.mail.yahoo.com/AAAA' after disabling qname minimization due to 'ncache nxdomain'
21-Mar-2024 14:58:36.371 validating ksg07.harvard.edu/MX: no valid signature found
21-Mar-2024 14:58:36.371 REFUSED unexpected RCODE resolving '3.gvt0.com/A/IN': 216.239.38.10#53
21-Mar-2024 14:58:36.379 success resolving 'a-0.19-21098801.c0c0083.1518.19d4.3ea1.210.0.qfptcsf437v6s7kaak2qs267pq.avqs.mcafee.com/A' after disabling qname minimization due to 'ncache nxdomain'
21-Mar-2024 14:58:36.387 REFUSED unexpected RCODE resolving 'www.untwistedvortex.com/A/IN': 128.199.213.165#53
21-Mar-2024 14:58:36.387 query client=0x7fa869b1f000 thread=0x7fa86cefd680(www.untwistedvortex.com/A): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.387 query client=0x7fa83b2d7000 thread=0x7fa85b3fe680(www.untwistedvortex.com/A): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.403 query.c:10467: INSIST(namereln == dns_namereln_subdomain) failed
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4651Add Dual Queue Low Latency Networking Support (NQB)2024-03-22T08:48:50ZJason LivingoodAdd Dual Queue Low Latency Networking Support (NQB)### Description
Add Dual Queue Low Latency Networking Support (NQB)
Please consider adding server-side support for IETF Non-Queue-Building (NQB) Per Hop Behavior (PHB) as outlined in the IETF TSVWG RFCs 9330, 9331, 9332 and https://dat...### Description
Add Dual Queue Low Latency Networking Support (NQB)
Please consider adding server-side support for IETF Non-Queue-Building (NQB) Per Hop Behavior (PHB) as outlined in the IETF TSVWG RFCs 9330, 9331, 9332 and https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/. Specifically, I would like the recursive resolver to set DSCP-45 marking in all packets sent back to users (stub resolvers) in DNS responses. This will have the benefit of marking DNS responses as suitable for placement in the low latency queue at bottleneck links supporting dual queue (such as a CMTS or Cable Modem).
NQB marking enables latency-sensitive traffic like DNS lookups to be handled in a separate queue from classic traffic. The result is that, even when competing with significant other LAN or access network traffic from a user, that the NQB-marked traffic will get very low working latency (usually close to what is observed for idle latency).
Comcast has tested this on resolvers in the lab as part of our low latency field trial of L4S and NQB and found it meaningfully reduced Query Response Times (QRT) under normal working conditions.
Comcast is currently the world's first ISP trialing this in the field and anticipates it being available to millions of end users in 2024.
### Request
Enable a new configuration parameter in the server enabling a resolver operator to turn on NQB support. That specifically will mean setting DSCP value 45 in the packet header. This configuration can either cover recursive responses or all outbound traffic from the server (there should be no downside to this).
### Links / references
RFC 9330 https://www.rfc-editor.org/rfc/rfc9330.html
RFC 9331 https://www.rfc-editor.org/rfc/rfc9331.html
RFC 9332 https://www.rfc-editor.org/rfc/rfc9332.html
NQB PHB Draft https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/
Comcast explainer for app developers https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/App-Developer-Guide.md
Comcast explainer for network operators https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/Network-Config-Guide.md
Comcast field trial announcement https://corporate.comcast.com/stories/comcast-kicks-off-industrys-first-low-latency-docsis-field-trialshttps://gitlab.isc.org/isc-projects/kea/-/issues/3302Is Host Cache required for RADIUS?2024-03-21T16:47:13ZFrancis DupontIs Host Cache required for RADIUS?The Host Cache was designed for RADIUS in order to not perform an access/auth exchange with the RADIUS server for each query: when the query comes from an already seen client (same RADIUS idenfier) the answer from the RADIUS server is av...The Host Cache was designed for RADIUS in order to not perform an access/auth exchange with the RADIUS server for each query: when the query comes from an already seen client (same RADIUS idenfier) the answer from the RADIUS server is available from the host cache. This was critical when both were designed because the access/auth exchange was synchronous (i.e. blocking until the answer is received) and single threaded (i.e. blocking the whole DHCP service). Perhaps it is less true today but the host cache is in memory when RADIUS exchanges are over the network so far slower, and the Host Cache also handles negative answers so covers (excepting for the bug described in #3269) all cases.
The Host Cache has a second function for RADIUS: when the RADIUS server returns an address (vs a pool name which is translated into a client class name directly added to the query object) a host entry for this reserved address is inserted in the Host Cache. The idea is the host lookup will be able to find it. This is not essential: the host entry can be attached to the callout handle associated to the query and got back latter as the current code does for the [re]selected subnet.