ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-07T22:43:18Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4553return value for check DS shadows value for running keymgr2024-03-07T22:43:18ZMatthijs Mekkingmatthijs@isc.orgreturn value for check DS shadows value for running keymgrChecking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.Checking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4552keymgr: bug in Depends function2024-03-13T10:53:30ZMatthijs Mekkingmatthijs@isc.orgkeymgr: bug in Depends functionWhile working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certa...While working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certain record type is going to be swapped. For example, with the ZSK Pre-Publish rollover method the signatures created by the successor key `z` are being propagated first, so that the zone signatures for `x` and `z` can be swapped (smooth rollover). In this case, we say that `z` is the successor of `x` for the `ZRRSIG` record type. Here, `x` is the predecessor key that is going to be withdrawn from the zone. The set `Dep(x, T)` is a separately administrated set of keys that have a dependency on `x` for record type `T`.
For example, with the ZSK Pre-Publish method, the `ZRRSIG` records of key `x` can be withdrawn if there is a succeeding `ZRRSIG` of key `z` introduced in the zone. Key `x` now depends on key `z`, therefore `z` will be in the set `Dep(x, ZRRSIG)`. The successor relation requires that the predecessor key must not have any other keys relying on it. In other words, the set `Dep(x, T)` must be empty.
---
But if the key is phased out (all its states are in `HIDDEN`), there is no longer a dependency. Since the relationship is still maintained (`Predecessor` and `Successor` metadata), the `keymgr_dep` function still returned `true`. In other words, the set `Dep(x, T)` is not considered empty.
This slows down key rollovers, only retiring keys when the successor key has been fully propagated.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/4551dnssec-keygen man page contradictory on whether TSIG keys can be generated2024-03-08T05:39:15ZChristopher Headdnssec-keygen man page contradictory on whether TSIG keys can be generated### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the secti...### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the section for the `-a` option:
> In prior releases, HMAC algorithms could be generated for use as TSIG keys, but that feature was removed in BIND 9.13.0. Use tsig-keygen to generate TSIG keys.
It looks like the top matter probably wasn’t updated when TSIG was spun out into `tsig-keygen`.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4549heap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddone2024-03-08T07:52:43ZMichal Nowakheap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddoneJob [#3977008](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3977008) failed for 6b00e831e1f7dad6c02766721f3f921935f9d82d in the `shutdown` system test.
```
WARNING: ThreadSanitizer: heap-use-after-free
Write of size 8 at 0x0000000...Job [#3977008](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3977008) failed for 6b00e831e1f7dad6c02766721f3f921935f9d82d in the `shutdown` system test.
```
WARNING: ThreadSanitizer: heap-use-after-free
Write of size 8 at 0x000000000001 by main thread:
#0 ccmsg_senddone lib/isccc/ccmsg.c:160 (BuildId: d832ce616f43e7826d71895c29b8d1a636594d28)
#1 isc___nm_sendcb netmgr/netmgr.c:1882 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#2 isc__job_cb lib/isc/job.c:78 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#3 uv__run_idle /usr/src/libuv-v1.47.0/src/unix/loop-watcher.c:68 (BuildId: 073e85ad3e8928fc579b193a4ac75e2ebba7da2f)
#4 thread_body lib/isc/thread.c:85 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#5 isc_thread_main lib/isc/thread.c:116 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#6 isc_loopmgr_run lib/isc/loop.c:454 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#7 main bin/named/main.c:1574 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
Previous write of size 8 at 0x000000000001 by main thread:
#0 free <null> (BuildId: 732e44e7f1cd4f0f9ca7d27895a253bebdea6827)
#1 sdallocx lib/isc/jemalloc_shim.h:82 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#2 mem_put lib/isc/mem.c:328
#3 isc__mem_put lib/isc/mem.c:692
#4 conn_free bin/named/controlconf.c:597 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
#5 controlconnection_unref bin/named/controlconf.c:200
#6 controlconnection_detach bin/named/controlconf.c:200 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
#7 control_senddone bin/named/controlconf.c:284 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
#8 ccmsg_senddone lib/isccc/ccmsg.c:159 (BuildId: d832ce616f43e7826d71895c29b8d1a636594d28)
#9 isc___nm_sendcb netmgr/netmgr.c:1882 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#10 isc__job_cb lib/isc/job.c:78 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#11 uv__run_idle /usr/src/libuv-v1.47.0/src/unix/loop-watcher.c:68 (BuildId: 073e85ad3e8928fc579b193a4ac75e2ebba7da2f)
#12 thread_body lib/isc/thread.c:85 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#13 isc_thread_main lib/isc/thread.c:116 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#14 isc_loopmgr_run lib/isc/loop.c:454 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#15 main bin/named/main.c:1574 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
SUMMARY: ThreadSanitizer: heap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddone
```
We had a similar issue #4501 before.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/3238Sanity checks for Kea 2.5.5 rc12024-02-20T10:26:54ZWlodzimierz WencelSanity checks for Kea 2.5.5 rc1We are now at step SANITY CHECKS of Kea 2.5.5 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-co...We are now at step SANITY CHECKS of Kea 2.5.5 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks) and according to your imagination.
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
#### Tarballs on repo.isc.org
* `/data/shared/sweng/kea/releases/2.5.5-rc1`
* `/data/shared/sweng/kea/releases/premium-2.5.5-rc1`
* `/data/shared/sweng/kea/releases/subscription-2.5.5-rc1`
* `/data/shared/sweng/kea/releases/enterprise-2.5.5-rc1`
```
SHA256 (kea-2.5.5.tar.gz) = 77918ea7ccb9bc89756c3e52a26adf515b91e47dbf258027fa973f68eff82f67
SHA256 (kea-enterprise-2.5.5.tar.gz) = 8041d0fd418846c36dc51dc0b64cb820ba46c5d1ec392990f2d30068272c3013
SHA256 (kea-premium-2.5.5.tar.gz) = b376b98480dcf31435d72f42edfc194ba41c3864dacd12fd3d46f43f5ae9d6c4
SHA256 (kea-subscription-2.5.5.tar.gz) = ae4b940a984d80fa93d0f9130bb1fdf41c15cf29858a46dbbf8a5eda98119768
```
#### Packages on packages.aws.isc.org
* [APK: 2.5.5-r20240129145054](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20240129145054.apk)
* [deb: 2.5.5-isc20240129145054](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.5.5-isc20240129145054)
* [RPM: 2.5.5-isc20240129145054.\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.5.5-isc20240129145054*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-dev/job/pkg/1407/
Instructions for installing packages are at point 9 of [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks).kea2.5.6Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3237Changes for Kea 2.5.5 release2024-01-29T14:39:11ZWlodzimierz WencelChanges for Kea 2.5.5 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.5.5Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/32362.5.5 release checklist2024-01-31T19:24:29ZWlodzimierz Wencel2.5.5 release checklist# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the actual fr...# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the actual freeze. For new stable releases or maintenance releases, please don't use the `kea-dev` build farm; use a dedicated build farm for each release cycle.
1. [x] Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html) in Jenkins for drops in performance.
1. [x] Create a Gitlab issue for bumping up library versions and `KEA_HOOKS_VERSION` and notify developers.
* In case of no developers available, it can be done by running: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that).
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. [x] If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. [x] Prepare release notes.
1. [x] Create release note on Kea GitLab wiki and notify @tomek. It should be created under the `Release-Notes` directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.3.4
1. [x] Finish release notes and conduct its review.
1. [x] Notify support that release notes are ready for review. To avoid conflicts in edits wait with next step after review is done.
1. [x] Notify @sgoldlust or @vicky that release notes are ready for review. Due to time difference please do this at least 36 hours before planned release.
1. [ ] Check that packages can be uploaded to cloudsmith.
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick the latest pkg build in the `Packages` field, and the corresponding tarball build in the `Tarball` field, leave the rest as they are `PrivPubRepos: "private"`, `TarballOrPkg: "packages"`, `TestProdRepos: "testing"` and click `Build`.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) \
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 2.3.4 --repo-dir ~/isc/repos/kea/`. \
Help: `GITLAB_TOKEN='...' ./update-code-for-release.py --help`. \
The script requires an explicit flag for stable and maintenances releases e.g. `--repo-branch v2_4`. \
The script makes the following changes and actions:
1. Runs [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/prepare_kea_release.sh) that:
1. Adds release entries in ChangeLogs.
1. Updates Kea version in configure.ac.
1. Updates copyright years in files that were changed in current year.
1. Sorts message files.
1. Regenerates message files headers.
1. Regenerates parsers using Bison from Docker
1. [x] Run the script again with the `--upload-only` flag which:
1. Creates an issue in GitLab for release changes in kea repo.
1. Creates branches and merge requests for kea and kea-premium.
1. Commits the changes in both repos.
1. Checks out created branches in both repos.
1. Commits and pushes the changes to GitLab server.
1. [x] Check manually User's Guide sections:
1. [x] Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed.
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. [x] Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. [x] Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/)).
1. [x] Check and update Build Requirements.
1. [x] Check configure options against what `./configure -h` says.
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages up to date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. It's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid.
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick:
1. `rc1` if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. Submit the job that will automatically:
1. Upload the tarballs.
1. Create a GitLab issue for sanity checks, put the announcement there.
1. Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.\
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
Now it's time to publish the code.
1. [x] Update Release Notes with ChangeLog entries.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. `Kea-2.3.4`).
1. Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description:
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/).
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/).
1. [x] Upload final tarballs to repo.isc.org.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick `final`. This job will also:
- Open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org.
- Create Git tags `Kea-a.b.c` in Kea main and premium repositories.
- Create Gitlab releases `Kea-a.b.c` in Kea main and premium repositories.
1. [x] Sign tarballs with the personal key, by running [sign_kea_and_upload_asc.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh) which signs, verifies signatures and uploads them.
- If release engineer does NOT have signing key, please contact team member.
1. [x] Confirm that the tarballs have the checksums mentioned on the signing ticket.
1. [ ] Wait for clearance from Security Officer to proceed with the public release (if applicable). If this is a security release, next steps will be impacted by CVE checklist.
1. [x] Login to repo.isc.org and upload final tarball to public ftp using the make-available script.
* Example command: `make-available --public --symlink=cur/2.3 /data/shared/sweng/kea/releases/2.3.4`.
* [x] For premium tarballs use `--private` option.
* For more information use `--debug` option.
* To overwrite existing content, use `--force` option.
* If you did a mistake, contact ASAP someone from the ops team to remove incorrectly uploaded tarballs.
* [x] save links to all premium tarballs and put them into signing ticket as a comment.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io:
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick your selected pkg build in the `Packages` field, the corresponding tarball build in the `Tarball` field, `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build`.
- This step also verifies sign files.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [ ] Check that Docker images can be uploaded to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/).
* Make sure the right package job is selected under `Packages`.
* Tick `Upload`.
* Leave `TestProdRepos` to `testing`.
* Leave `versionTag` ticked.
* Tick `latestTag` if this is a stable or a maintenance release.
* If this is a stable or maintenance release, change `KeaDockerBranch` to the appropriate branch.
* Press `Build`.
1. [x] Build and upload Docker images to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/) with the same actions as above except change `TestProdRepos` to `production`.
1. [x] Update ReadTheDocs:
1. Trick ReadTheDocs into pulling the latest tags. Click `Build version` on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. If it's a stable release, change the default version to point to this stable release. `Admin -> Advanced Settings -> Default version* -> Kea-a.b.c`.
1. [x] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` most of the time, or
* `a.y.0-git` where `y == b + 2` if a new development series starts, or
* `x.1.0-git` where `x == a + 1` when the released minor version `b` is 9 and `a.b.c` was the last version in the development series and a new development version is coming up next.
1. [x] Contact Marketing team, and find a member who will continue work on this release:
1. [x] Assign this ticket to person who will continue.
1. [x] Share link to signing ticket either directly or as a comment in this issue.
## Marketing
1. [x] Publish links to downloads on ISC website.
1. [x] Update the supported versions document in the Salesforce portal (if there are stable versions released), and update the Kea document in the portal.
1. [x] If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Verify that the KB on installing from Cloudsmith has also been updated, then update the Kea document in the SF portal and notify support customers that this new private repo exists.
1. [x] If a new Cloudsmith repository is used, make sure that the Zapier scripts are updated.
* If those are not updated, there was an error made during preparation for new stable release. Please contact QA team and coordinate fix.
1. [x] Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
1. [x] Write release email to _kea-announce_.
1. [x] Write email to _kea-users_ (if a major release).
1. [ ] Announce on social media.
1. [x] Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea\_(software)).
1. [x] Write blog article (if a major release).
1. [x] Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
1. [x] Update Kea Premium and Kea Subscription data sheets if any new hooks.
1. [ ] Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
1. [x] Contact Support team, find a person who will continue this release and assign this issue to them.
## Support
1. [x] Update tickets in case of waiting for support customers.
1. [x] Close this ticketkea2.5.5https://gitlab.isc.org/isc-projects/kea/-/issues/3235bump up lib versions for 2.5.52024-01-26T17:03:30ZWlodzimierz Wencelbump up lib versions for 2.5.5as stated in the subject ;)as stated in the subject ;)kea2.5.5Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3234Update Kea Premium License text2024-01-29T14:40:19ZVicky Riskvicky@isc.orgUpdate Kea Premium License textThe Kea Premium license text has been updated to version 2.1.1. I made a MR over in the Premium repo but I don't know how to tell for sure if the license text has to go in headers for multiple files, or just in the 'copying' file at the ...The Kea Premium license text has been updated to version 2.1.1. I made a MR over in the Premium repo but I don't know how to tell for sure if the license text has to go in headers for multiple files, or just in the 'copying' file at the top of the tree.kea2.5.5https://gitlab.isc.org/isc-projects/stork/-/issues/1286Make tarball task optional2024-02-01T22:58:52ZSlawek FigielMake tarball task optionalThe `tarball` CI task tries to download some artifacts from other tasks, although they are not needed. It sometimes fails.
[Source](https://gitlab.isc.org/isc-projects/stork/-/jobs/3965088)
```
Preparing the "docker+machine" executor
0...The `tarball` CI task tries to download some artifacts from other tasks, although they are not needed. It sometimes fails.
[Source](https://gitlab.isc.org/isc-projects/stork/-/jobs/3965088)
```
Preparing the "docker+machine" executor
00:24
Using Docker executor with image registry.gitlab.isc.org/isc-projects/stork/ci-base:3 ...
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image registry.gitlab.isc.org/isc-projects/stork/ci-base:3 ...
Using docker image sha256:4579cce3c0c8b1f05031a797d08e081c184777f80ef4a11f0ea325ba533e2c99 for registry.gitlab.isc.org/isc-projects/stork/ci-base:3 with digest registry.gitlab.isc.org/isc-projects/stork/ci-base@sha256:373b00e8c068bd4798d8340a20ee31d2aea1fb21a7ec6409217a1a7c75b82f2a ...
Preparing environment
00:23
Running on runner-4ylmhpa7-project-87-concurrent-0 via runner-4ylmhpa7-gitlab-docker-runner-1706108027-e915d800...
Getting source from Git repository
00:04
Fetching changes...
Initialized empty Git repository in /builds/isc-projects/stork/.git/
Created fresh repository.
Checking out e5b5702b as detached HEAD (ref is refs/merge-requests/699/head)...
Skipping Git submodules setup
Downloading artifacts
02:43
Downloading artifacts for build_ui (3965074)...
Downloading artifacts from coordinator... ok host=gitlab.isc.org id=3965074 responseStatus=200 OK token=64_3MZNy
Downloading artifacts for build_doc (3965075)...
Downloading artifacts from coordinator... ok host=gitlab.isc.org id=3965075 responseStatus=200 OK token=64_3MZNy
Downloading artifacts for build_backend (3965076)...
Downloading artifacts from coordinator... ok host=gitlab.isc.org id=3965076 responseStatus=200 OK token=64_3MZNy
WARNING: tools/python/bin/python: chmod tools/python/bin/python: no such file or directory (suppressing repeats)
Downloading artifacts for build_backend_legacy (3965077)...
Downloading artifacts from coordinator... ok host=gitlab.isc.org id=3965077 responseStatus=200 OK token=64_3MZNy
Downloading artifacts for build_debs_amd64 (3965080)...
Downloading artifacts from coordinator... ok host=gitlab.isc.org id=3965080 responseStatus=200 OK token=64_3MZNy
Downloading artifacts for build_debs_arm64 (3965081)...
Downloading artifacts from coordinator... ok host=gitlab.isc.org id=3965081 responseStatus=200 OK token=64_3MZNy
Downloading artifacts for build_rpms_amd64 (3965082)...
Downloading artifacts from coordinator... ok host=gitlab.isc.org id=3965082 responseStatus=200 OK token=64_3MZNy
Downloading artifacts for build_rpms_arm64 (3965083)...
Downloading artifacts from coordinator... ok host=gitlab.isc.org id=3965083 responseStatus=200 OK token=64_3MZNy
Downloading artifacts for build_apks_amd64 (3965084)...
ERROR: Downloading artifacts from coordinator... not found host=gitlab.isc.org id=3965084 responseStatus=404 Not Found token=64_3MZNy
FATAL: file does not exist
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1
```1.15Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4547Add support for nginx load balancing with “X-Real-IP”2024-01-24T11:56:31ZMr BenAdd support for nginx load balancing with “X-Real-IP”### Description
When I use doh, I hope bind can be deployed behind nginx and also be able to identify the client source IP. I have some views, and the policies of these views are judged based on the source IP.
This is not currently supp...### Description
When I use doh, I hope bind can be deployed behind nginx and also be able to identify the client source IP. I have some views, and the policies of these views are judged based on the source IP.
This is not currently supported. Perhaps X-Real-IP should be added to the header of http, and the IP can be passed to the dns module to make policy judgments instead of the source IP of the IP layer.
### Request
Perhaps X-Real-IP should be added to the header of http, and the IP can be passed to the dns module to make policy judgments instead of the source IP of the IP layer.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4546Cannot Compile - Invalid Regex Prevents Generation of Parsetab Module2024-01-23T22:35:43ZOleg SCannot Compile - Invalid Regex Prevents Generation of Parsetab Module<!--
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
The Bind project (version 9.16.23) cannot be compiled due to regex
issues in the `bin/python/isc/policy.py` file.
Here is the output generated when running `make`:
### BIND version affected
9.16.23
### Steps to reproduce
1. On a Fedora 39 system (this probably applies beyond Fedora 39, too), with Python 3.12.1 installed,
simply clone the source code of the repo corresponding to
version 9.16.23.
2. Run `./configure` and ensure that it completes successfully
3. Run `make`
### What is the current *bug* behavior?
Make finishes prematurely because it cannot find the `parsetab` module.
### What is the expected *correct* behavior?
Make should be able to run the Python script and generate the `parsetab` module
successfully.
### Relevant configuration files
n/a
### Relevant logs
Here is the output of `make`:
```
/usr/bin/python policy.py parse /dev/null > /dev/null
ERROR: /home/olegs/Programming/cve-gen-ai/FixMorph/experiments/bind-backports/bind/bind-9.16.23/bin/python/isc/policy.py:63: Invalid regular expression for rule 't_DATESUFFIX'. missing -, : or ) at position 20
ERROR: /home/olegs/Programming/cve-gen-ai/FixMorph/experiments/bind-backports/bind/bind-9.16.23/bin/python/isc/policy.py:68: Invalid regular expression for rule 't_KEYTYPE'. global flags not at the start of the expression at position 14
ERROR: /home/olegs/Programming/cve-gen-ai/FixMorph/experiments/bind-backports/bind/bind-9.16.23/bin/python/isc/policy.py:73: Invalid regular expression for rule 't_ALGNAME'. global flags not at the start of the expression at position 14
PYTHONPATH=. /usr/bin/python -m parsetab
/usr/bin/python: No module named parsetab
make[3]: *** [Makefile:457: parsetab.py] Error 1
```https://gitlab.isc.org/isc-projects/kea/-/issues/3231PerfMon-Core-Task-3 Modify Dhcpv4Srv and Dhcpv6Srv to add packet events2024-02-20T18:22:47ZThomas MarkwalderPerfMon-Core-Task-3 Modify Dhcpv4Srv and Dhcpv6Srv to add packet eventsComplete Kea Core task 3 per PerfMon design: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#kea-core-tasksComplete Kea Core task 3 per PerfMon design: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#kea-core-taskskea2.5.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3230PerfMon-Core-Tasks-1-and-2 Create PktEvent Class Modify PktFilters2024-02-16T16:58:12ZThomas MarkwalderPerfMon-Core-Tasks-1-and-2 Create PktEvent Class Modify PktFiltersComplete Kea Core tasks 1 and 2 per PerfMon design: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#kea-core-tasksComplete Kea Core tasks 1 and 2 per PerfMon design: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#kea-core-taskskea2.5.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/stork/-/issues/1285Update project dependencies2024-02-05T18:03:23ZSlawek FigielUpdate project dependenciesWe should update Go, JavaScript, Python, and so on dependencies to fix bugs and security vulnerabilities.We should update Go, JavaScript, Python, and so on dependencies to fix bugs and security vulnerabilities.1.15Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/kea/-/issues/3229hammer.py prepare-system --just-configure2024-01-26T09:15:21ZAndrei Pavelandrei@isc.orghammer.py prepare-system --just-configureWe could use a way to just configure packages without installing them in hammer.We could use a way to just configure packages without installing them in hammer.kea2.5.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/61Reservations prints one blank reservation if no reservations specified2024-03-17T13:51:53ZDarren AnkneyReservations prints one blank reservation if no reservations specifiedIf no reservations are specified, then one blank reservation like this:
```
"reservations": [
{
"hw-address": "",
"hostname": "",
"client-classes": [
...If no reservations are specified, then one blank reservation like this:
```
"reservations": [
{
"hw-address": "",
"hostname": "",
"client-classes": [
""
]
}
],
```
is added. This causes the error:
```
2024-01-22 20:12:58.190 ERROR [kea-dhcp4.dhcp4/1304.281473680973840] DHCP4_PARSER_FAIL failed to create or run parser for configuration element reservations: empty host identifier used (test.json:78:13)
```
Disable addition of blank reservations section.
No need for a release note as this feature was introduced in this same version.0.3https://gitlab.isc.org/isc-projects/bind9/-/issues/4545Flamethrower DoH queries timeout with BIND on FreeBSD2024-03-04T16:12:33ZMichal NowakFlamethrower DoH queries timeout with BIND on FreeBSDIn "stress" CI jobs, we run three types of scenarios where we send thousands of UDP and TCP queries per second to an authoritative, recursive, or recursive RPZ server. Each scenario runs on Linux amd64, Linux arm64, and FreeBSD 12.4 amd6...In "stress" CI jobs, we run three types of scenarios where we send thousands of UDP and TCP queries per second to an authoritative, recursive, or recursive RPZ server. Each scenario runs on Linux amd64, Linux arm64, and FreeBSD 12.4 amd64 platforms. For a long time, I have tried to add support for DoT and DoH, and with the adoption of AWS for CI, this is now possible.
The major problem now is that there's something wrong with BIND-Flamethrower cooperation for DoH queries on FreeBSD 12.4 for all scenarios (authoritative, recursive, and recursive with RPZ). The problem is that Flamethrower 0.12 from upstream Git `master` - run on FreeBSD in CI or Linux in my local environment - never gets answers to DoH queries from BIND on FreeBSD (DoH on BIND on Linux is fine; DoT, TCP, and UDP on FreeBSD are fine as well). 100% of queries are timeouted. During the Flamethrower runtime, in the BIND `-d 99` log, there is only a lot of lines like this: `22-Jan-2024 14:39:14.040 socket 0x8030df800: TLS server session created for 192.168.122.1#43511 on 192.168.122.73#4430`. However, the query does not seem to be processed in any way. It gets processed fine when sent by `dig +https`.
See job [#3956703](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3956703) for logs and config files.
Here's a 10-second PCAP (`tcpdump port 4430 -i vtnet0`) from my local environment: [cap.pcap](/uploads/5b4bfee595db99cb92b220ce97eff697/cap.pcap).
Flamethrower output with 100% of timeouted queries:
<details><summary>Click to expand</summary>
```
/usr/local/bin/flame --dnssec -P doh -F inet -g file -f ~/Downloads/fbsddoh/query_datafile -Q 1 -p 4430 192.168.122.73
WARNING: QPS limit is less than concurrent senders, changing limit to 30
binding traffic generators to 0.0.0.0
flaming target(s) [192.168.122.73] on port 4430 with 30 concurrent generators, each sending 100 queries every 1000ms on protocol doh
query generator [file] contains 105000 record(s)
rate limit @ 30 QPS (1 QPS per concurrent sender)
1.1768e-05s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0
1.00012s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0
2.00152s: send: 30, avg send: 30, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 30, timeouts: 0
3.00237s: send: 0, avg send: 30, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 30, timeouts: 0
4.00255s: send: 0, avg send: 30, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 30, timeouts: 0
5.00297s: send: 90, avg send: 60, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 30
6.00343s: send: 0, avg send: 60, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
7.00418s: send: 0, avg send: 60, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
8.00446s: send: 90, avg send: 70, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 90
9.00494s: send: 0, avg send: 70, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
10.0056s: send: 0, avg send: 70, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
11.0064s: send: 90, avg send: 75, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 90
^C11.1595s: send: 0, avg send: 75, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 90, timeouts: 0
stopping, waiting up to 3s for in flight to finish...
------
run id : 7ffd5c99e030
run start : 2024-01-22T16:41:23Z
runtime : 14.1608 s
total sent : 300
total rcvd : 0
min resp : 0 ms
avg resp : -nan ms
max resp : 0 ms
avg r qps : 0
avg s qps : 75
avg pkt : 35.3258 bytes
tcp conn. : 568
timeouts : 300 (100%)
bad recv : 0
net errors : 0
```
</details>
BIND config file:
<details><summary>Click to expand</summary>
```
http local {
endpoints { "/dns-query"; };
};
options {
port 5300;
listen-on port 5300 { 10.53.0.2; };
listen-on-v6 port 5300 { fd92:7065:b8e:ffff::2; };
listen-on port 8530 tls ephemeral { 10.53.0.2; }; // DoT IPv4
listen-on-v6 port 8530 tls ephemeral { fd92:7065:b8e:ffff::2; }; // DoT IPv6
listen-on port 4430 tls ephemeral http local { 10.53.0.2; }; // DoH IPv4
listen-on port 4430 tls ephemeral http local { 192.168.122.73; }; // DoH IPv4
listen-on-v6 port 4430 tls ephemeral http local { fd92:7065:b8e:ffff::2; }; // DoH IPv6
#directory "/var/tmp/gitlab_runner/builds/e-TSUMFs/0/isc-projects/bind9/output/ns2";
allow-query { any ; };
query-source address 10.53.0.2;
pid-file "named.pid";
recursion no;
tcp-clients 50;
statistics-file "named.stats";
};
statistics-channels {
inet 10.53.0.2 port 5308 allow { any; };
};
key "rndc-key" {
algorithm hmac-sha256;
secret "G+hIujn1FwNv1QgEWLrzN8ZXodAHzciE7tMSYDIiw54=";
};
controls {
inet 10.53.0.2 port 5309
allow { any; } keys { "rndc-key"; };
};
include "trusted-keys.conf";
view "default" {
zone "." {
type hint;
file "root.hint";
};
zone "test.example." in {
type master ;
file "test.example.db.signed";
};
};
logging {
channel "namedlog" {
file "named.log" versions 5 size 50M;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"namedlog";
};
};
```
</details>
The `query_datafile` file is in the CI job artifact.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/kea/-/issues/3227config-set accepts incorrect "prefix-len" value2024-01-19T08:22:53ZPeter Daviesconfig-set accepts incorrect "prefix-len" value
---
name: config-set accepts incorrect "prefix-len" value
about: On kea-dhcp6 version 2.2.1 config-set accepts incorrect "prefix-len"
value and future config-get and config-write calls fail.
---
**Describe the bug**
Given the follo...
---
name: config-set accepts incorrect "prefix-len" value
about: On kea-dhcp6 version 2.2.1 config-set accepts incorrect "prefix-len"
value and future config-get and config-write calls fail.
---
**Describe the bug**
Given the following subnet definition ( within a shared-network)
```
"subnet": "2a02:6b67:fc00:31::/64",
"id": 2,
"pd-pools": [{
"prefix": "2a02:6b67:ed70::",
"prefix-len": 44,
"delegated-len": 56}],
```
Kea starts correctly and config-* commands function as expected.
Change "prefix-len": 44, to "prefix-len": 38, and run "config-test" with this
invalid configuration. The command returns "result": 0,
```
[root@blaenau agent]# ./config-test6
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5776 100 147 100 5629 143 5507 0:00:01 0:00:01 --:--:-- 5662
[
{
"result": 0,
"text": "Configuration seems sane. Control-socket, hook-libraries, and D2 configuration were sanity checked, but not applied."
}
]
```
Run config-set with this invalid configuration and it also returns 0
```
[root@blaenau agent]# ./config-set6
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5684 100 56 100 5628 53 5411 0:00:01 0:00:01 --:--:-- 5475
[
{
"result": 0,
"text": "Configuration successful."
}
]
````
Now try and retrieve the running configuration with config-get or config-write.
```
[root@blaenau agent]# ./config-get6
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 191 100 141 100 50 10071 3571 --:--:-- --:--:-- --:--:-- 15916
[
{
"result": 1,
"text": "Error during command processing: invalid prefix range 2a02:6b67:ed70::-2a02:6b67:efff:ffff:ffff:ffff:ffff:ffff"
}
]
```
```
[root@blaenau agent]# ./config-write6
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 269 100 134 100 135 13400 13500 --:--:-- --:--:-- --:--:-- 38428
[
{
"result": 1,
"text": "Error during write-config:invalid prefix range 2a02:6b67:ed70::-2a02:6b67:efff:ffff:ffff:ffff:ffff:ffff"
}
]
````
Strangely after accepting the invalid configuration Kea appears to start sending
logging to stdout. the last message in the Kea log file is:
```
2024-01-19 01:52:35.014 INFO [kea-dhcp6.commands/97719.140321550017664] COMMAND_RECEIVED Received command 'config-set'
```
Correcting "prefix-len" and re-runing config-set re-enables the retrieval of the
running config but not the logging issue.
I haven't test if lease processing is affected by this.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv6 with the attached configuration file [
2. change the prefix-len to some invalid value via config-set
3. The server then appears to accept the configuration but efforts to retrieve
the runing configuration fail
4. See above
**Expected behavior**.
When running config-test Kea ought to have discovered the configuration error
and reported it.
When running config-set Kea ought to have discovered the configuration error
and reported it.
**Environment:**
- Kea version: 2.2.1
tarball
linked with:
log4cplus 1.2.0
OpenSSL 1.1.1k FIPS 25 Mar 2021
database:
Memfile backend 4.0
- OS: Oracle Linux 8"
- none
- none
**Additional Information**
This does not affect 2.5.4 which generates the following error:
```
2024-01-18 14:53:13.667 ERROR [kea-dhcp6.dhcp6/431892.140413956814720] DHCP6_PARSER_FAIL failed to create or run parser for configuration element shared-networks: Invalid Pool6 address boundaries: 2a02:6b67:ed70:: is not the first address in prefix: 2a02:6b67:ec00::/38 (<wire>:0:3314) (<wire>:0:2401)
```
**SalesForce**
[#00001600](https://isc.lightning.force.com/lightning/r/Case/500S6000003m9ybIAA/view)https://gitlab.isc.org/isc-projects/bind9/-/issues/4541values of ruletype field for update-policy statement2024-03-08T05:30:58Zperlangvalues of ruletype field for update-policy statementOne document typo, version 9.18.21, doc/arm/reference.rst, line 7492,
It is only 18 values from the list.
```
The ruletype field has 20 values: ``name``, ``subdomain``, ``zonesub``,
``wildcard``, ``self``, ``selfsub``, ``selfwild``...One document typo, version 9.18.21, doc/arm/reference.rst, line 7492,
It is only 18 values from the list.
```
The ruletype field has 20 values: ``name``, ``subdomain``, ``zonesub``,
``wildcard``, ``self``, ``selfsub``, ``selfwild``, ``ms-self``,
``ms-selfsub``, ``ms-subdomain``, ``ms-subdomain-self-rhs``, ``krb5-self``,
``krb5-selfsub``, ``krb5-subdomain``, ``krb5-subdomain-self-rhs``,
``tcp-self``, ``6to4-self``, and ``external``.
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)