ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-06-30T09:53:14Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2209reservation-get-by-hostname: subnet-id not in response if it is in request2022-06-30T09:53:14ZAndrei Pavelandrei@isc.orgreservation-get-by-hostname: subnet-id not in response if it is in requestExpected `subnet-id` to be contained in response regardless of arguments.
This is useful when users switch between API calls and they expect the response to be the same when, for example, they parse the response or they chain API calls.Expected `subnet-id` to be contained in response regardless of arguments.
This is useful when users switch between API calls and they expect the response to be the same when, for example, they parse the response or they chain API calls.kea2.1.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2086Subnet id limits are not enforced2022-06-23T19:26:12ZPeter DaviesSubnet id limits are not enforcedKea 9.11: According to the ARM "Subnet IDs must be greater than zero and less than 4294967295."
However no configuration error appears to be generated when a subnet with an id greater than this is used?
```
{
"id": 102552...Kea 9.11: According to the ARM "Subnet IDs must be greater than zero and less than 4294967295."
However no configuration error appears to be generated when a subnet with an id greater than this is used?
```
{
"id": 10255255025,
"subnet": "10.0.0.0/24",
"pools": [
{
"pool": "10.0.0.50 - 10.0.0.201" } ]
}
]
```
Subnet id 10255255025 becomes 1665320433.
```
2021-09-01 09:16:29.465 DEBUG [kea-dhcp4.hosts/4035250.140148899886976] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1665320433 and IPv4 address 10.0.0.160
```
kea-lease4.csv:
```
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context
10.0.0.50,98:ee:cb:4c:22:8f,,600,1631520296,1665320433,0,0,,0,
```
[RT #19141](https://support.isc.org/Ticket/Display.html?id=19141)kea2.1.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1706HA support for TLS / HTTPS2022-06-23T15:44:17ZFrancis DupontHA support for TLS / HTTPSI propose to use the same 4 parameters as in #1662 but the HA case is more complex because the config can be global or per peer i.e. with some kind of inheritance to design.I propose to use the same 4 parameters as in #1662 but the HA case is more complex because the config can be global or per peer i.e. with some kind of inheritance to design.kea2.1.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1614Make Kea compatible with OpenSSL 3.02022-06-24T15:49:13ZFrancis DupontMake Kea compatible with OpenSSL 3.0kea2.1.7Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2458hammer fix for ubuntu 22.042022-06-27T12:06:53ZWlodzimierz Wencelhammer fix for ubuntu 22.04kea2.1.7Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/24562.1.7 release checklist2022-06-30T11:02:32ZMarcin Godzina2.1.7 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 those 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 those checks and updates can be made before the actual freeze.
1. Check Jenkins results:
1. [ ] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [ ] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [ ] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/Kea_20Build_20Checks/)
1. [ ] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./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. 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. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-2.1.0
1. [x] Finish release notes and conduct its review
1. [ ] Run [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [ ] Make sure access tokens have been 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.
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) <br>
Example command: `GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
The script:
- creates Gitlab issue and MR for release changes
- adds release entries to ChangeLogs
- regenerates BNF grammar
- regenerates documentation
- regenerates messages
- reorders messages in alphabetical order
- regenerates parsers
- updates copyright dates
- pushes the changes to MR
1. Check manually User's Guide sections:
1. 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. 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. 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 [tarball-internal](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/) 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 all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page 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-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
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. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
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
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- send a signing request issue link on the DHCP Mattermost channel
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs 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. For stable releases, change the default version to point to this stable release.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever: <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button: <br>
1. [tarball-internal job](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
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` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Wait for the signing ticket from the release engineer.
- [x] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [x] ***(Support)*** Sign the tarballs.
- [x] ***(Support)*** Upload signature files to repo.isc.org.
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [x] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [x] ***(Support)*** 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. Then update support customers that this new private repo exists.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [x] ***(Marketing)*** 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.
- [x] ***(Marketing)*** Announce on social media.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [x] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [x] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [x] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).kea2.1.7Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/2453fix rhel 9 + pgsql build in hammer2022-06-24T09:57:24ZWlodzimierz Wencelfix rhel 9 + pgsql build in hammerkea2.1.7Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2431Add support for client-class::user-context to PostgreSQL config backend2022-06-08T13:43:43ZThomas MarkwalderAdd support for client-class::user-context to PostgreSQL config backendAdd support for client-class:user-context to PostgreSQL config backendAdd support for client-class:user-context to PostgreSQL config backendkea2.1.7Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2403Improve Hooks Libraries list in ARM left-hand column2022-06-14T18:42:19ZThomas MarkwalderImprove Hooks Libraries list in ARM left-hand columnThe ARM's display of the Hook Libraries section in the left-hand column is really getting hard to navigate. With each new hook it gets worse.
1. The library name after the number (when present) is much smaller than the numbers or topic...The ARM's display of the Hook Libraries section in the left-hand column is really getting hard to navigate. With each new hook it gets worse.
1. The library name after the number (when present) is much smaller than the numbers or topic
2. The items are inconsistent, most have the name, then topic but not all (BOOTP vs the rest)
3. Fonts are inconsitent (class_cmds vs cb_cmds)
4. There doesn't seem to be an inherent scheme to the ordering beyond the order they were developed. I think alphabetical would probably be more intuitive and useful.
I also just noticed that section 16.4 appears to be out of date, neither Postgresql CB or DDNS tuning are missing from the table. Postgresql CB and MySQL CB are missing from the section listing.
It might also be nice if there were links to each hook's section in the table 16.4.
Also, this section "16.22. User Contexts in Hooks" would be better placed under 16.3 as 16.3.1, rather than at the end of the Hooks chapter itself. It applies to more than one hook and deals with their configuration.kea2.1.7Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3437CDS error window too small2022-07-05T13:12:27ZMark AndrewsCDS error window too smallJob [#2622252](https://gitlab.isc.org/isc-private/bind9/-/jobs/2622252) failed for isc-private/bind9@36c4446d40e7765d0fec46109cf9e765ed7c3147:
It looks like we need to allow 10 seconds instead of 3 seconds
also `D:cds:stderr did not ma...Job [#2622252](https://gitlab.isc.org/isc-private/bind9/-/jobs/2622252) failed for isc-private/bind9@36c4446d40e7765d0fec46109cf9e765ed7c3147:
It looks like we need to allow 10 seconds instead of 3 seconds
also `D:cds:stderr did not match ''` is spurious. It should only be emitted when we are searching for $err.
```
I:cds:correct signature inception time (13)
D:cds:stderr did not match ''
D:cds:bad inception time 3609 at checktime.pl line 27, <> line 28.
I:cds:failed
D:cds:exit status does not match 0
I:cds:failed
I:cds:in-place reads modification time (14)
```
```
dnssec-cds: child records must not be signed before 20220704070137 (1656918097)
dnssec-cds: which child DNSKEY records match parent DS records?
dnssec-cds: no matching DS for DNSKEY 58053 8
dnssec-cds: found matching DS 38830 8 1
dnssec-cds: no matching DS for DNSKEY 23492 8
dnssec-cds: verify DNSKEY signature(s)
dnssec-cds: skip RRSIG by key 23492: no matching (C)DS
dnssec-cds: found RRSIG by key 38830
dnssec-cds: this is the oldest so far 20220704080146 (1656921706)
dnssec-cds: skip RRSIG by key 58053: no matching (C)DS
dnssec-cds: verify CDS signature(s)
dnssec-cds: skip RRSIG by key 23492: no matching (C)DS
dnssec-cds: found RRSIG by key 38830
dnssec-cds: skip RRSIG by key 58053: no matching (C)DS
dnssec-cds: child signature inception time 20220704080146 (1656921706)
dnssec-cds: from RRSIG DNSKEY by key 38830
dnssec-cds: which child DNSKEY records match new DS records?
dnssec-cds: no matching DS for DNSKEY 58053 8
dnssec-cds: found matching DS 38830 8 1
dnssec-cds: no matching DS for DNSKEY 23492 8
dnssec-cds: verify DNSKEY signature(s)
dnssec-cds: skip RRSIG by key 23492: no matching (C)DS
dnssec-cds: found RRSIG by key 38830
dnssec-cds: skip RRSIG by key 58053: no matching (C)DS
dnssec-cds: debug 1: calling free_rbtdb(cds.test)
dnssec-cds: debug 1: done free_rbtdb(cds.test)
dnssec-cds: debug 1: calling free_rbtdb(cds.test)
dnssec-cds: debug 1: done free_rbtdb(cds.test)
```July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/3433Use a default HMAC algorithm in system tests2022-07-22T05:08:10ZMark AndrewsUse a default HMAC algorithm in system testsThe default HMAC algorithm used for RNDC and DNS requests is system should be easily updatable.
Prerequisite for !4281The default HMAC algorithm used for RNDC and DNS requests is system should be easily updatable.
Prerequisite for !4281July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/3429New issue 48509 by ClusterFuzz-External: bind9:dns_master_load_fuzzer: Intege...2022-07-07T08:33:16ZMark AndrewsNew issue 48509 by ClusterFuzz-External: bind9:dns_master_load_fuzzer: Integer-overflow in genname```
Detailed Report: https://oss-fuzz.com/testcase?key=5954650567737344
Project: bind9
Fuzzing Engine: libFuzzer
Fuzz Target: dns_master_load_fuzzer
Job Type: libfuzzer_ubsan_bind9
Platform Id: linux
Crash Type: Integer-overflow
Crash ...```
Detailed Report: https://oss-fuzz.com/testcase?key=5954650567737344
Project: bind9
Fuzzing Engine: libFuzzer
Fuzz Target: dns_master_load_fuzzer
Job Type: libfuzzer_ubsan_bind9
Platform Id: linux
Crash Type: Integer-overflow
Crash Address:
Crash State:
genname
generate
load_text
Sanitizer: undefined (UBSAN)
Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_bind9&range=202202240600:202202250603
Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5954650567737344
```
Test case:
```
$GENERATE 1-1 <FF> 0 type4 ${2147483647
```
`<FF>` is octet 0xff
```
0000000 24 47 45 4e 45 52 41 54 45 20 31 2d 31 20 ff 20
0000020 30 20 74 79 70 65 34 20 24 7b 32 31 34 37 34 38
0000040 33 36 34 37
0000044
```
```
732 n = snprintf(numbuf, sizeof(numbuf), fmt,
733 it + delta);
```
`it + delta` overflows.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/3422Documentation clarifications on dnssec-policy and dynamic zones2023-09-19T09:22:12ZMatthijs Mekkingmatthijs@isc.orgDocumentation clarifications on dnssec-policy and dynamic zonesSection 4.2.28 (dnssec-policy Statement Definition and Usage) should probably mention that inline-signing is implicitly enabled unless the zone is a dynamic zone, and should also reference (i.e. link to) section 4.2.36.4?
Section 4.2.36....Section 4.2.28 (dnssec-policy Statement Definition and Usage) should probably mention that inline-signing is implicitly enabled unless the zone is a dynamic zone, and should also reference (i.e. link to) section 4.2.36.4?
Section 4.2.36.4 (Dynamic Update Policies) should outline the consequences (of using dynamic zones) on zone file management, including:
The zone file can no longer be manually updated while named is running, without first performing rndc freeze and then after editing performing rndc thaw.
Comments and formatting in the zone file will be lost when dynamic updates (including DNSSEC signing) occur?July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3420rrsetorder system test succeeds despite of a failure log line2022-06-23T10:52:19ZArаm Sаrgsyаnrrsetorder system test succeeds despite of a failure log linehttps://gitlab.isc.org/isc-projects/bind9/-/jobs/2589750
```
...
...
I:rrsetorder:Random selection return 12 of 24 possible orders in 36 samples
I:rrsetorder:failed
I:rrsetorder:Checking order none (cache)
I:rrsetorder:Checking default ...https://gitlab.isc.org/isc-projects/bind9/-/jobs/2589750
```
...
...
I:rrsetorder:Random selection return 12 of 24 possible orders in 36 samples
I:rrsetorder:failed
I:rrsetorder:Checking order none (cache)
I:rrsetorder:Checking default order (cache)
I:rrsetorder:Default selection return 12 of 24 possible orders in 36 samples
I:rrsetorder:Checking default order no match in rrset-order (cache)
I:rrsetorder:exit status: 0
I:rrsetorder:stopping servers
R:rrsetorder:PASS
E:rrsetorder:2022-06-20T14:30:48+0000
PASS: rrsetorder
```
Seems to be a missing case of `status=$((status+ret))`.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3416ZSK rollover dnssec-policy: key lifetime is shorter than the time it takes to...2023-12-28T12:16:42ZTom ShawZSK rollover dnssec-policy: key lifetime is shorter than the time it takes to do a rollover<!--
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 do *NOT* report it here, but send an
email to [...<!--
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 do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Setting up DNSSec using a dnssec policy a previously working configuration now fails due to the Key duration and roll over periods being too "short".
### BIND version used
```
BIND 9.19.2-1+ubuntu22.04.1+isc+1-Ubuntu (Development Release) <id:>
running on Linux x86_64 5.15.0-39-generic #42-Ubuntu SMP Thu Jun 9 23:42:32 UTC 2022
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-YovKit/bind9-9.19.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.2.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.44.1
linked to libuv version: 1.44.1
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Use the policy provided below and apply this to a zone.
### What is the current *bug* behavior?
Service fails to start.
### What is the expected *correct* behavior?
I should expect the dnssec-policy set to honour the configuration. A warning at best, would be appropriate here. This configuration worked in the previous development release.
The duration of the keys is a security consideration and not something BIND should enforce. If I want my keys to roll over every hour, I should be able to allow this.
The warning provides a 30day message when in fact the security policy (provided below) allows BIND to start. It would be useful to see some sort of timeline view in the docs relating to the config values for a dnssec policy as the values are unexplained and best guess values have been used.
### Relevant configuration files
none working config
```
dnssec-policy "standard" {
keys {
ksk lifetime PT120M algorithm ECDSAP384SHA384;
zsk lifetime PT40M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT3M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT1M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT60M;
signatures-validity-dnskey PT60M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
```
working modified config (less than 30d)
```
dnssec-policy "standard" {
keys {
ksk lifetime PT120M algorithm ECDSAP384SHA384;
zsk lifetime PT55M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT3M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT1M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT40M;
signatures-validity-dnskey PT40M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
```
### Relevant logs and/or screenshots
```
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:43: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:66: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:67: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:67: dnssec-policy: key lifetime is shorter than the time it takes to do a ro>
Jun 17 16:22:02 ninja.flipkick.media named[2161]: loading configuration: failure
Jun 17 16:22:02 ninja.flipkick.media named[2161]: exiting (due to fatal error)
Jun 17 16:22:02 ninja.flipkick.media systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE
```
### Possible fixes
Allow any period for key duration. 30 days is a poor security policy when working with an Edge computing system and I have resolved the CDS/DS key updates https://github.com/flipkickmedia/cme-dnssec-service - I can get a fully working dnssec system up and running in seconds. With this new update, I have to wait 30d to see if the system works.
I would expect a warning at best, and my TLD providers update the DS keys when I update them (<3H)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3415"rndc reconfig" does not reload http statements2024-01-11T14:13:02ZThomas Beati"rndc reconfig" does not reload http statements### Summary
When we add an endpoint in an http statement in named.conf and run ```rndc reconfig```, the new endpoint is not effective. \
Bind needs to be restarted for the endpoint to be effective. \
The reconfig was working in 9.18.2.
...### Summary
When we add an endpoint in an http statement in named.conf and run ```rndc reconfig```, the new endpoint is not effective. \
Bind needs to be restarted for the endpoint to be effective. \
The reconfig was working in 9.18.2.
### BIND version used
Bug introduced in 9.18.3
BIND 9.18.3 (Stable Release) <id:16aefa3>
### Steps to reproduce
1) Bind is started as an http server:
```
http local-http-server {
endpoints {
"/endpoint1/dns-query";
};
};
option {
...
listen-on port 8443 tls tls_conf http local-http-server {any;};
...
}
```
2) Add an endpoint in named.conf :
```
http local-http-server {
endpoints {
"/endpoint1/dns-query";
"/endpoint2/dns-query";
};
};
```
3) Run ```rndc reconfig```
### What is the current *bug* behavior ?
Configuration is not reloaded, the new endpoint responds with 404 error.
### What is the expected *correct* behavior?
Configuration is reloaded, the new endpoint responds to dns queries.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3412systems/test/run.sh to pass through VIRTUAL_ENV and PERL5LIB2022-06-23T10:45:14ZStacey Marshallsystems/test/run.sh to pass through VIRTUAL_ENV and PERL5LIB### Description
Have tests/system use required Python (dnspython) and PERL modules (Digest::HMAC and Net::DNS) from
user directories, avoid using privileges.
### Request
Have run.sh pass Python virtualenv variable `VIRTUAL_ENV` and PE...### Description
Have tests/system use required Python (dnspython) and PERL modules (Digest::HMAC and Net::DNS) from
user directories, avoid using privileges.
### Request
Have run.sh pass Python virtualenv variable `VIRTUAL_ENV` and PERL's
`PERL5LIB` from user environment to make (gmake).
```
--- run.sh.in.orig 2022-06-16 10:52:39.000000000 +0100
+++ run.sh.in 2022-06-16 11:00:23.000000000 +0100
@@ -90,6 +90,8 @@
LOG_FLAGS="$log_flags" \
TEST_LARGE_MAP="${TEST_LARGE_MAP}" \
CI_ENABLE_ALL_TESTS="${CI_ENABLE_ALL_TESTS}" \
+ ${VIRTUAL_ENV:+"VIRTUAL_ENV=${VIRTUAL_ENV}"} \
+ ${PERL5LIB:+"PERL5LIB=${PERL5LIB}"} \
make -e check
exit $?
fi
```
Note: The *pythonenv* must be setup to use the same version of python as the test uses, for example /usr/bin/python.
### Links / references
Python's virtual environments are well documented.
- [Virtual Environments and Packages](https://docs.python.org/3/tutorial/venv.html)
Perl's use of PERL5LIB is not so well documented,
- [Search www.perl.COM for PERL5LLIB](https://www.google.com/search?q=PERL5LIB+site%3Awww.perl.COM).
- A good summary can be found on [Stackoverlflow](https://stackoverflow.com/questions/2526804/how-is-perls-inc-constructed-aka-what-are-all-the-ways-of-affecting-where-pe)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3408Drop support for Debian 9 (Stretch)2022-07-15T11:05:43ZPetr Špačekpspacek@isc.orgDrop support for Debian 9 (Stretch)LTS version of Debian 9 reaches EOL on [2022-06-30](https://wiki.debian.org/DebianReleases).
Proposal:
- [x] drop it from .gitlab-ci.yaml on all supported branches
- [x] stop bothering ourselves with libraries and Python versions used b...LTS version of Debian 9 reaches EOL on [2022-06-30](https://wiki.debian.org/DebianReleases).
Proposal:
- [x] drop it from .gitlab-ci.yaml on all supported branches
- [x] stop bothering ourselves with libraries and Python versions used by Debian 9
- [x] drop it from list of Regularly Tested Platforms in the ARM
- [x] update [KB article](https://kb.isc.org/docs/supported-platforms)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3402synth-from-dnssec might prevent resolution of grafted (non-delegated) namespaces2022-07-07T09:58:47ZPetr Špačekpspacek@isc.orgsynth-from-dnssec might prevent resolution of grafted (non-delegated) namespaces### Summary
This is all about setup where delegation chain is incomplete and `named.conf` is configured to "graft" a domain without delegation.
Example setup:
- public root zone does not have delegation for `internal`
- named.conf cont...### Summary
This is all about setup where delegation chain is incomplete and `named.conf` is configured to "graft" a domain without delegation.
Example setup:
- public root zone does not have delegation for `internal`
- named.conf contains forwarding or stub zone for `test.internal`
### BIND version used
- ~"Affects v9.19": v9_19_2
- ~"Affects v9.18": v9_18_2
- ~"Affects v9.16": 5c327f209b4bdd9cda8e50c2808b5253321868c0
### Steps to reproduce
1. Configure graft:
```
options {
validate-except { internal; };
synth-from-dnssec yes;
};
zone test.internal {
type forward;
forwarders { 192.0.2.1; };
forward only;
};
```
2. Query for `internal2` to populate cache with proof-of-nonexistence from the root zone:
```
# dig internal2
```
3. Query for a name inside the grafted domain:
```
# dig bla.test.internal
```
### What is the current behavior?
Synthesized NXDOMAIN, based on proof from the root:
```
;; AUTHORITY SECTION:
. 86399 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022061400 1800 900 604800 86400
```
### What is the expected (_not necessarily correct!_) behavior?
A customer was surprised by this after upgrade from ~"v9.16" to ~"v9.18". Technically this is incorrect configuration and qualifies as squatting on a ICANN namespace, but it might not be as rare as we would wish.
### Relevant configuration files
Tested variants with the same result:
- `validate-except { test.internal; };`
- static-stub zone for test.internal
- primary zone for `internal` + forward zone for `test.internal` without delegation
- primary zone for `internal` + forward zone for `test.internal` **with** a "fake" delegation from `internal.` to `test.internal` - **this surprised me**
- primary zone for `internal` + static-stub zone for `test.internal` **with** a "fake" delegation from `internal.` to `test.internal` - **this surprised me** ([empty.db](/uploads/85816fc0dbc6786d760d297eb16bfd32/empty.db) [named.conf](/uploads/025f10df1fff9216ac4accf0b7938974/named.conf))
### Possible approaches
We need to discuss what's the best approach to this protocol-wise invalid configuration. Variants I came up with:
- [ ] Leave it as it is and let users suffer consequences of non-compliant configurations.
- [ ] Except zones listed in `validate-except` also from `synth-from-dnssec`.
- :skull_crossbones: Introduce a new knob for exceptions, like `synth-from-dnssec-except`.
- [ ] Ignore proofs of nonexistence from parent zones for explicitly configured zones (does not include type forward because it's not in the zone table)
- [x] Ignore proofs of nonexistence from parent zones for explicitly configured grafts (includes local zones + the forward table)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3401race condition in route_connected() leads to crash on startup/shutdown2022-06-14T20:06:20ZPetr Špačekpspacek@isc.orgrace condition in route_connected() leads to crash on startup/shutdown### Summary
Assertion failure in route_connected()->in ns_interfacemgr_attach():
```
#6 0x00007f901a31bab8 in ns_interfacemgr_attach (source=0x7f9015294000, target=0x7f901677aaf8) at interfacemgr.c:418
418 REQUIRE(NS_INTERFACEMGR_VALI...### Summary
Assertion failure in route_connected()->in ns_interfacemgr_attach():
```
#6 0x00007f901a31bab8 in ns_interfacemgr_attach (source=0x7f9015294000, target=0x7f901677aaf8) at interfacemgr.c:418
418 REQUIRE(NS_INTERFACEMGR_VALID(source));
```
### BIND version used
- ~"Affects v9.19" : v9_19_2
- ~"Affects v9.18" : v9_18_4
It seems that ~"v9.16" is not affected, or at least is not easily reproducible. I was not able to crash it after 2000 iterations and has given up.
### Steps to reproduce
Easiest reproducer so far is this Bash loop:
```shell
for I in $(seq 1 1000); do /tmp/main/sbin/named -g -c /dev/null -n1 2>&1 & sleep 0.0$RANDOM; pkill named; done
```
### What is the current *bug* behavior?
Crash after couple hundred iterations.
### What is the expected *correct* behavior?
Well, no crash :-)
### Relevant configuration files
None, see `-c /dev/null`.
### Relevant logs and/or screenshots
[gdb.log](/uploads/b55e7fd115e84085ae1f630551424d84/gdb.log)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Arаm SаrgsyаnArаm Sаrgsyаn