ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-08-31T20:40:30Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2055release 1.9.112021-08-31T20:40:30ZWlodzimierz Wencelrelease 1.9.11---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# 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. [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/tarball-internal/Kea_20Build_20Checks/)
1. [x] 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. 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-1.9.2
1. [x] Finish release notes and conduct its review
1. [x] 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.
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 a Kea issue and MR for release changes,
- runs several updating scripts
- 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 sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed lib versions
1. which were updated? (save results)
1. any of the lib from current release has lower number then corresponding lib from 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] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
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] 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.
### On the Day of Public Release
- [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** If it is a new major 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.
- [ ] ***(Support)*** Update tickets in case of waiting for support customers.
- [x] ***(QA)*** Inform Marketing of the release.
- [ ] ***(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.
- [ ] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).
## Post-Release, But Before Code Unfreeze
- [x] 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`kea1.9.11Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2054ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES via statistics API2022-02-17T17:56:06ZEverett FultonALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES via statistics APIIn https://support.isc.org/Ticket/Display.html?id=18994 Support customer would like a new API function to obtain statistics on allocation failures.
These events are currently logged, and show as:
2021-08-18 09:21:38.256 WARN [kea-dhcp4...In https://support.isc.org/Ticket/Display.html?id=18994 Support customer would like a new API function to obtain statistics on allocation failures.
These events are currently logged, and show as:
2021-08-18 09:21:38.256 WARN [kea-dhcp4.alloc-engine/480.140451601748032] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 xx:xx:xx:xx:xx:xx], cid=[01:xx:xx:xx:xx:xx:xx], tid=0x4f2c435d: failed to allocate an IPv4 address after 3 attempt(s)
2021-08-18 09:21:38.256 WARN [kea-dhcp4.alloc-engine/480.140451601748032] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 xx:xx:xx:xx:xx:xx], cid=[01:xx:xx:xx:xx:xx:xx], tid=0x4f2c435d: Failed to allocate an IPv4 address for client with classes: ALL, HA_server1, UNKNOWNkea2.1.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2053bump up libs and hooks versions for 1.9.11 release2021-08-27T10:30:04ZRazvan Becheriubump up libs and hooks versions for 1.9.11 releasekea1.9.11https://gitlab.isc.org/isc-projects/bind9/-/issues/2884Sometimes dig aborts on an AXFR query over TLS2021-11-04T13:43:09ZCesar KuroiwaSometimes dig aborts on an AXFR query over TLS<!--
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
Sometimes (not always) `dig` crashes with a core dump on a AXFR query over TLS
### BIND version used
DiG 9.17.17
### Steps to reproduce
Using dig to make successive AXFR requests over TLS, using a HMAC-SHA256 TSIG key
```
% dig @<server> -p 853 +tls bom axfr -y hmac-sha256:<tsig-key>:<secret>
```
### Relevant logs and/or screenshots
```
bom. 172800 IN SOA a.dns.br. hostmaster.registro.br. 2021238532 1800 900 604800 900
bom. 21600 IN DNSKEY 256 3 13 fBrEkmLy0X3ANfdXKdkj8fNPAUbwhpC5VvlBaQMzi+8h63iePUcM/dcT aJVVpWgas+HgkKlA3wCTAAFuJJ1uCA==
bom. 21600 IN DNSKEY 257 3 13 jBWA/GVSitmW8erjfZc6plKFXq2j8OOR5FR+3qgAz8nM8yW4+8egKfNO fV1ynbGKAzOzyiC3xuGm7x3RfPXmNg==
bom. 172800 IN NSEC3PARAM 1 0 10 D5193D4EFD6031FF646F
tsig-gtlds. 0 ANY TSIG hmac-sha256. 1630015887 300 32 xcJBeqP007hmCBgx9MXXGbN1m6MieWJJUJzQOGhPhrE= 9519 NOERROR 0
nic.bom. 3600 IN NS ns.dns.br.
nic.bom. 3600 IN NS ns2.dns.br.
nic.bom. 3600 IN DS 40126 13 2 2B666C945F28C2ADA55279798382CC1BCA19DED7A32E3E0B1680FE84 4B1C154F
nic.bom. 3600 IN RRSIG DS 13 2 3600 20210903143501 20210819133501 16861 bom. az4R7y6/rjAQia9lTlcjcISj182zosM35mIlSlub108MrMXVbOZUsrzZ 3rHNKGch4j23G0ljP8ELgo5+L3AGNw==
bom. 172800 IN NS a.dns.br.
bom. 172800 IN NS b.dns.br.
bom. 172800 IN NS c.dns.br.
bom. 172800 IN NS d.dns.br.
bom. 172800 IN NS e.dns.br.
bom. 172800 IN NS f.dns.br.
bom. 21600 IN RRSIG DNSKEY 13 1 21600 20210915000000 20210611000000 14600 bom. a8Tag5dWGGgKNF0nbZfIO+ODDnaDstPjrE7BG7rRojU+KUw8uewTN/Yd 5PrgjC4wUBVbaDTNkG0evhO9dGmVXA==
bom. 172800 IN RRSIG SOA 13 1 172800 20210910221001 20210826211001 16861 bom. 23yXB1pgr7N+SdI1MtDKELA7Vrjt7/rWT1wx5AXPbNXNBFiEPBRE30Fo vJE4fBT0l5ZLbffEfJKm65XmBGBtjw==
bom. 172800 IN RRSIG NSEC3PARAM 13 1 172800 20210910221001 20210826211001 16861 bom. LzCugkc0fnBsssqz7zkj/gasbnjKy5zkSWRrfgFI2c5HW6KpQ2ImXfSG xFtJgaVWl5+QjDWNzaMVublFHe/A5A==
bom. 172800 IN RRSIG NS 13 1 172800 20210910221001 20210826211001 16861 bom. kMcSAe8somkybKerjoCV8WG0WfnUXLAO88b0sutOrAVFJR1X4655hw9R CQZKqsC3RpqnDPcbN2QSVT91wcU5jg==
6mom8bvsn8og38k5j20nubclk3l258vi.bom. 900 IN RRSIG NSEC3 13 2 900 20210903143501 20210819133501 16861 bom. zSfR9WRP+xHbBflvdOpTQDleukg+sTaTB62FvPNC15pxroPkRdTlIOLW jg54yxwye+bBcnHH+HWRtzF0QbfxOA==
6mom8bvsn8og38k5j20nubclk3l258vi.bom. 900 IN NSEC3 1 1 10 D5193D4EFD6031FF646F SD3KLP44SLP2IB3IRND61I31V6ROG2PE NS DS RRSIG
sd3klp44slp2ib3irnd61i31v6rog2pe.bom. 900 IN RRSIG NSEC3 13 2 900 20210910221001 20210826211001 16861 bom. NL2n5iahzZF59faktxT+x22UA8548NwIoDZc/WHub8wdQ02F134kq0Uo 8NbEzvKJdB0/FQNWf222+l5HWYJzOw==
sd3klp44slp2ib3irnd61i31v6rog2pe.bom. 900 IN NSEC3 1 1 10 D5193D4EFD6031FF646F 6MOM8BVSN8OG38K5J20NUBCLK3L258VI NS SOA RRSIG DNSKEY NSEC3PARAM
bom. 172800 IN SOA a.dns.br. hostmaster.registro.br. 2021238532 1800 900 604800 900
tsig-gtlds. 0 ANY TSIG hmac-sha256. 1630015887 300 32 Y1j1OjfZqqmzPHeTvNvVrEIfiK4UbMLiWntNw/Vo5A4= 9519 NOERROR 0
;; Query time: 1 msec
;; WHEN: Thu Aug 26 19:11:27 -03 2021
;; XFR size: 23 records (messages 2, bytes 1777)
netmgr/netmgr.c:1703: REQUIRE(((__builtin_expect(!!((handle) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1)) && __c11_atomic_load(&(handle)->references, memory_order_seq_cst) > 0)) failed, back trace
0x8002ba7a0 <isc_assertion_setcallback+0x50> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002ba74a <isc_assertion_failed+0xa> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002aae6b <isc__nm_get_read_req+0x11b> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b5295 <isc__nm_tlsdns_processbuffer+0x95> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002ab338 <isc__nm_process_sock_buffer+0x48> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b4926 <isc__nm_async_tlsdnsshutdown+0x366> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b5565 <isc__nm_tlsdns_read_cb+0xb5> at /home/cesar/named/lib/libisc-9.17.17.so
0x8007c5590 <uv__stream_init+0x500> at /usr/local/lib/libuv.so.1
0x8007cc12b <uv__io_poll+0x82b> at /usr/local/lib/libuv.so.1
0x8007bb551 <uv_run+0x1b1> at /usr/local/lib/libuv.so.1
0x8002a4deb <isc__netmgr_create+0x71b> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002e9914 <isc__trampoline_run+0x54> at /home/cesar/named/lib/libisc-9.17.17.so
Abort (core dumped)
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2883Let name of inline-signed zone file be configured2023-11-02T16:26:08ZMagnus HolmgrenLet name of inline-signed zone file be configured### Description
The names of journal files can be overridden (with `journal`), but not the names of the signed zone files created when `inline-signing=yes`. They are always named like the original file with `.signed` appended. https://g...### Description
The names of journal files can be overridden (with `journal`), but not the names of the signed zone files created when `inline-signing=yes`. They are always named like the original file with `.signed` appended. https://gitlab.isc.org/isc-projects/bind9/-/blob/2872d6a12efe578360a641c1ba90884ea9a7dd01/bin/named/zoneconf.c#L1116
It's not a huge deal, but I'd like to separate manually edited configuration from software managed data per the FHS, and thus keep non-dynamic master zones in /etc (which is also what the Debian package recommends) but the inline-signed zone data in /var/lib. (It appears that the Debian BIND maintainers didn't consider inline signing, because the included AppArmor profile prevents `named` from writing to /etc/bind.)
### Request
Define a new option `signed-file` or similar. Could something like [signed-file.patch](/uploads/ec5f66b98f5c986d867ea76ccc4a89d9/signed-file.patch) work?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2882Remove the "map" zone file format from 9.17+2022-01-19T11:20:48ZPetr Špačekpspacek@isc.orgRemove the "map" zone file format from 9.17+Configuration option `masterfile-format map` is complex and thus fragile (e.g. #2872, #2878).
Currently benchmarks do not show significant benefit when compared to `masterfile-format raw`.
Tests on real `net.` zone
--------------------...Configuration option `masterfile-format map` is complex and thus fragile (e.g. #2872, #2878).
Currently benchmarks do not show significant benefit when compared to `masterfile-format raw`.
Tests on real `net.` zone
-------------------------
Zone serial 1629331223, obtained from czds.icann.org.
| format | load time [s] | % of text time |
|--------|---------------|----------------|
| map | 17,4 | 25 % |
| raw | 28,4 | 40 % |
| text | 70,8 | 100 % |
File size comparison:
| format | size | N- of text size |
|--------|------------|-----------------|
| map | 4880695376 | 5,1 |
| raw | 1509720581 | 1,6 |
| text | 960525608 | 1,0 |
Tests on an artificial flat zone
---------------------------------
Zone generated by:
```bash
perl bin/tests/startperf/mkzonefile.pl test 34674952 > /tmp/text
```
| format | load time [s] | % of text time |
|--------|---------------|----------------|
| map | 36 | 25 % |
| raw | 48 | 34 % |
| text | 144 | 100 % |
File size comparison:
| format | size | N- of text size |
|--------|------------|-----------------|
| map | 9430522392 | 9,8 |
| raw | 1386860577 | 1,4 |
| text | 960521110 | 1,0 |
Summary
-------
Speedup provided by the `map` format does not seem significant enough to warrant the complexity of map format, especially when we take into account that the difference measured in terms of "real time" is in order of 10s of seconds.
Maybe we should mark it as deprecated in ~v9.17 & ~v9.18 and remove remove it in v9.19 timeframe.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/kea/-/issues/2052./configure without parameters fails on CentOS 7 if openssl11-devel is installed2021-10-04T08:34:16ZAndrei Pavelandrei@isc.org./configure without parameters fails on CentOS 7 if openssl11-devel is installed1. Install openssl11-devel
2. ./configure
3. `Missing required boost ssl header file`
Because Kea needs to link with Boost 1.69 from `boost169-devel` and it can't find it on its own.
Workaround is to install `boost169-devel` and also p...1. Install openssl11-devel
2. ./configure
3. `Missing required boost ssl header file`
Because Kea needs to link with Boost 1.69 from `boost169-devel` and it can't find it on its own.
Workaround is to install `boost169-devel` and also provide these: `--with-boost-include=/usr/include/boost169 --with-boost-lib-dir=/usr/lib64/boost169`.kea2.1.0https://gitlab.isc.org/isc-projects/bind9/-/issues/2881bind 9 can not balance load with mode order cyclic2021-08-26T07:07:39Zqimangebind 9 can not balance load with mode order cyclicI configured bind as dns server on **centos 8** and create a zone file named test.com.zone,the contents as follow:
```
$TTL 1D
@ IN SOA test.com. root.test.com. (
2020072603 ; serial
...I configured bind as dns server on **centos 8** and create a zone file named test.com.zone,the contents as follow:
```
$TTL 1D
@ IN SOA test.com. root.test.com. (
2020072603 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
@ IN NS master.test.com.
@ IN NS slave.test.com.
slave IN A 100.100.5.21
master IN A 100.100.5.22
www IN A 101.101.5.21
www IN A 101.101.5.22
www IN A 101.101.5.23
www IN A 101.101.5.24
www IN A 101.101.5.25
www IN A 101.101.10.245
www IN A 101.101.10.246
www IN A 101.101.10.247
www IN A 101.101.10.248
www IN A 101.101.10.249
```
the Subnet Mask of ip in resource records above is all 16 bits,when i ping www.test.com from client for 10 times,the ip it allocates is 101.101.5.21 for 6 times and 101.101.5.22~25,it can not allocate the ip of 101.101.10.x,is it any limit for the ip in resource records?
and then I modified the resource records in zone file as follow:
```
www IN A 101.101.5.21
www IN A 101.101.5.22
www IN A 101.101.5.23
www IN A 101.101.5.24
www IN A 101.101.5.25
www IN A 101.101.5.26
www IN A 101.101.5.27
www IN A 101.101.5.28
www IN A 101.101.5.29
www IN A 101.101.5.30
```
and I also ping www.test.com from client for 10 times,when the clients' operarte system is centos 8,it can Poll all the ip(101.101.5.21~30) correctly,but when the clients' operarte system is centos 7,the ip it allocates is 101.101.5.21 for 5 times and 101.101.5.22~26,why does it happen?https://gitlab.isc.org/isc-projects/stork/-/issues/574No information about the network in the prometheus exporter stork agent2021-11-03T13:46:34ZOleg ZeibelNo information about the network in the prometheus exporter stork agent---
name: Feature request
about: In the prometheus exporter of the agent, you need to show information about the network
---
**Some initial questions**
- Are you sure what you would like to do is not possible using some other mechanisms...---
name: Feature request
about: In the prometheus exporter of the agent, you need to show information about the network
---
**Some initial questions**
- Are you sure what you would like to do is not possible using some other mechanisms?
I have not found how to do it differently
- Stork is in very early stages of development. If your request is not simple, it
may be a while until anyone does anything with your request. Are you ok with that?
Yes
**Is your feature request related to a problem? Please describe.**
Stork prometheus exporter does not provide any information about the DHCP network. Network ID only.
This id has a numerical value and in the graphana dashboard this indicator is not at all visual.
**Describe the solution you'd like**
I would like to see information about the network. For example, in this form
kea_dhcp4_addresses_assigned_total{subnet="10.10.10.0/24"} 3
kea_dhcp4_addresses_declined_reclaimed_total{subnet="10.10.10.0/24"} 0
and other
**Describe alternatives you've considered**
Now we are trying to display the network through the grafana dashboard and the selection of the network ID
**Contacting you**
e-mail: iceadler@gmail.com / o.zejbel@robo.finance0.22Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2880timing issues with rndc system test2021-08-31T13:34:11ZMark Andrewstiming issues with rndc system testJob [#1940981](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1940981) failed for aae53e215678690df2fc857f05c9d409b6276104:
The test does not wait for the post freeze zone writes to complete.
```
I:rndc:checking update (68)
I:rndc:rn...Job [#1940981](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1940981) failed for aae53e215678690df2fc857f05c9d409b6276104:
The test does not wait for the post freeze zone writes to complete.
```
I:rndc:checking update (68)
I:rndc:rndc freeze
I:rndc:edit zone files
I:rndc:rndc thaw
I:rndc:rndc reload
I:rndc:ns7 server reload successful
I:rndc:checking zone file edits are loaded (69)
I:rndc:failed
I:rndc:exit status: 1
```
```
grep '\(test/IN\|'"'"'\(reload\|freeze\|thaw\)'"'"'\|all zones loaded\)' ns7/named.run
...
25-Aug-2021 00:27:36.398 received control channel command 'freeze'
25-Aug-2021 00:27:36.398 zone_dump: zone test/IN/internal: enter
25-Aug-2021 00:27:36.398 freezing zone 'test/IN' internal: success
25-Aug-2021 00:27:36.398 zone_gotwritehandle: zone test/IN/internal: enter
25-Aug-2021 00:27:36.430 received control channel command 'thaw'
25-Aug-2021 00:27:36.434 zone test/IN/internal: starting load
25-Aug-2021 00:27:36.434 zone_startload: zone test/IN/internal: enter
25-Aug-2021 00:27:36.434 thawing zone 'test/IN' internal: success
25-Aug-2021 00:27:36.442 dump_done: zone test/IN/internal: enter
25-Aug-2021 00:27:36.442 zone_journal_compact: zone test/IN/internal: target journal size 336
25-Aug-2021 00:27:36.442 zone test/IN/internal: dns_journal_compact: success
25-Aug-2021 00:27:36.442 zone_loaddone: zone test/IN/internal: enter
25-Aug-2021 00:27:36.442 zone test/IN/internal: number of nodes in database: 4
25-Aug-2021 00:27:36.442 zone test/IN/internal: loaded; checking validity
25-Aug-2021 00:27:36.442 dns_zone_verifydb: zone test/IN/internal: enter
25-Aug-2021 00:27:36.442 zone test/IN/internal: ixfr-from-differences: unchanged
25-Aug-2021 00:27:36.442 zone_postload: zone test/IN/internal: done
25-Aug-2021 00:27:36.466 received control channel command 'reload'
...
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2879Add --disable-doh to a CI build?2023-11-02T16:26:08ZMark AndrewsAdd --disable-doh to a CI build?The following discussion from !5353 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5353#note_231504): (+1 comment)
> One remaining question is "do we add yet ano...The following discussion from !5353 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5353#note_231504): (+1 comment)
> One remaining question is "do we add yet another system with --disable-doh to CI?"
- [ ] Also should we have a CI build that does not have libnghttp2 installed.Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/2051lease commands hook library should not use MultiThreadCriticalSections2021-08-26T13:41:38ZThomas Markwalderlease commands hook library should not use MultiThreadCriticalSectionsCommands to add or update leases currently attempt to create MultiThreadCriticalSection(s) when they are unable to lock the target IP address. The original idea was that by entering CS all other work would stop and the update would be c...Commands to add or update leases currently attempt to create MultiThreadCriticalSection(s) when they are unable to lock the target IP address. The original idea was that by entering CS all other work would stop and the update would be carried out. However, with HA+MT, the commands are being run by worker threads, which are not allowed to create critical sections. With the advent of #2043, attempting to create a CS will always fail, thus it would be better to simply fail when a lock cannot be obtained (or possibly retry), and fail with an error indicating a conflicting update. Thus the caller can decide what action to take.
There is little point in them attempting to create critical sections, thus the code should simply be removed.kea1.9.11Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2878zonefiles in map format larger than 2 GiB cannot be read but can be written (...2021-09-15T21:06:34ZPetr Špačekpspacek@isc.orgzonefiles in map format larger than 2 GiB cannot be read but can be written (data loss)### Summary
Large zones written in `masterfile-format map;` with files larger than 2 GiB cannot be read.
### BIND version used
It affects latest commits on all supported branches:
- main 042d206bf499119dd16efc452718cb03a728d960
- v9_1...### Summary
Large zones written in `masterfile-format map;` with files larger than 2 GiB cannot be read.
### BIND version used
It affects latest commits on all supported branches:
- main 042d206bf499119dd16efc452718cb03a728d960
- v9_16 713ded2cc37037a5c63b61c00cc41b7de0328996
- v9_11 0480e212bf4b70f52e5a24e8ef3849a94c627a84
### Steps to reproduce
1. Generate a zone file which results in map file larger than 2 GiB:
```bash
perl bin/tests/startperf/mkzonefile.pl test 8000000 > /tmp/text
```
2. Convert text zone file into `map` format:
```bash
named-compilezone -i none -k ignore -m ignore -M ignore -n ignore -r ignore -S ignore -T ignore -W ignore -f text -F map -o /tmp/map test /tmp/text
```
3. Attempt to read the zone:
```bash
named-checkzone -i none -k ignore -m ignore -M ignore -n ignore -r ignore -S ignore -T ignore -W ignore -f map test /tmp/map
```
### What is the current *bug* behavior?
```
zone test/IN: loading from master file /tmp/map failed: invalid file
zone test/IN: not loaded due to errors.
```
### What is the expected *correct* behavior?
Zone can be read and the data are intact, obviously.
### Possible fixes
The main question is how much we want to invest into the `map` format. If we decide to remove RBTDB map format in favor of a different data structure, we might consider a low-cost option: Limit file size to make it "safe" and remove the format a bit later.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/dhcp/-/issues/204dhcrelay -6 does not work if there are interface aliases up in the system2022-03-09T19:02:55ZSantiagodhcrelay -6 does not work if there are interface aliases up in the systemHi there,
I've been hit by this issue on Debian stretch through sid (the latest including 4.4.1, I've been unable to test on 4.4.2).
dchrelay -6 doesn't start if there are interface aliases up in the
system:
```
# /usr/sbin/dhcrel...Hi there,
I've been hit by this issue on Debian stretch through sid (the latest including 4.4.1, I've been unable to test on 4.4.2).
dchrelay -6 doesn't start if there are interface aliases up in the
system:
```
# /usr/sbin/dhcrelay -6 -pf /var/run/dhcrelay6.pid -l vlan.881 -u 2001:db8:cafe::2%vlan.880
Internet Systems Consortium DHCP Relay Agent 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Bound to *:547
Listening on Socket/vlan.881:0
Sending on Socket/vlan.881:0
Listening on Socket/vlan.880:0
Sending on Socket/vlan.880:0
Listening on Socket/vlan
Sending on Socket/vlan
setsockopt: IPV6_JOIN_GROUP: Address already in use
If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug. These pages explain the proper
process and the information we find helpful for debugging.
exiting.
```
The above error can be reproduced with inside a container with the following /etc/network/interfaces:
```
auto lo
iface lo inet loopback
auto vlan
iface vlan inet dhcp
auto vlan.880
auto vlan.880:0
iface vlan.880 inet static
address 192.168.133.1/24
iface vlan.880 inet6 static
address 2001:db8:cafe::1/64
iface vlan.880:0 inet static
address 10.0.133.1/16
auto vlan.881
auto vlan.881:0
iface vlan.881 inet static
address 192.168.131.1/24
iface vlan.881 inet6 static
address 2001:db8:cafe:1::1/64
iface vlan.881:0 inet static
address 10.1.131.1/16
```
Just removing (or commenting out) the interface aliases entries makes dchrelay -6 happy (again).
Please note the `-l` and `-u` filters do not work. But that's another bug.
This seems similar to #88. The patch attached there doesn't fix the problem.Outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2050Provide basic configuration templates for sample use cases2024-03-21T12:45:56ZVicky Riskvicky@isc.orgProvide basic configuration templates for sample use casesWe have a number of example configurations in a separate file in the Kea distribution. These show how to use different features of Kea. The problem is, a new user is looking for a template to cut and paste to start with.
What we would ...We have a number of example configurations in a separate file in the Kea distribution. These show how to use different features of Kea. The problem is, a new user is looking for a template to cut and paste to start with.
What we would like is to **add example configurations that a user will recognize as 'probably fits my needs', and document these in the ARM**. The example configuration descriptions should include what we are assuming the requirements are for that scenario, what lease lifetimes, traffic levels and so on we expect, and what hardware/sw we suggest. If we can import the configurations into the ARM, great, or we else we can link to the json files. Then we can refer them to the existing examples for how to add the xyz feature, if their scenario requires that and we didn't include it.
These example configurations could be included as an appendix to the ARM or in the Getting Started section.
We might want a handful of these eventually, starting with the simplest and most common.
* [x] **power home user** - 256 addresses, dhcpv4 or ipv6 pd, wants failover with v. inexpensive hw, minimal traffic, no dbs. !1418
* [ ] **small organization** - several small dhcpv4 subnets, 20 host reservations, failover, memfile, guest wifi plus 'internal' users. Low traffic Maybe we could model this on the old ISC hq?
* [ ] **multi-site enterprise** - DHCPv4 and DHCPv6. multiple clusters each serving local geography. 100s of host reservations, 1000s of clients, failover (within a site), separate guest network/wifi, possibly captive portal to register?)
* [ ] **hub and spokes enterprise**, such as retail (dozens to hundreds of locations with local failover, centralized configuration mgmt, likely dhcpv4 only legacy devices with odd vendor options....).
* [ ] **small wired service provider** (1-3 data centers, <100K subs, v4 and v6 w/pd, failover, multi-threading, forensic logging, classification for premium, known and unknown users, home gateways with RFC 1918, 3-4 addresses per gw. e.g. small municipal fiber provider
* [ ] **large wired service provider** (>3 data centers, >100K subs, v4 and v6 with pd, config backend. Some ability to identify premium users. e.g. Cable access provider, cable modems.
* [ ] **wireless service provider** (not sure how this is different, except perhaps much shorter lease times, higher traffic for the same number of users, more likely to be v6? highest performance configuration, captive portal)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2049AX_FIND_LIBRARY false negative (solves NETCONF support in FreeBSD and NETCONF...2021-11-03T16:08:09ZAndrei Pavelandrei@isc.orgAX_FIND_LIBRARY false negative (solves NETCONF support in FreeBSD and NETCONF unit tests in Alpine & CentOS)The code was written to look for both lib and lib64 for libraries, but it always stops at `lib` if it couldn't find the library, so `lib64` is forgotten due to bad logic in m4macro code. Affects NETCONF in FreeBSD.
Here is an ut-extende...The code was written to look for both lib and lib64 for libraries, but it always stops at `lib` if it couldn't find the library, so `lib64` is forgotten due to bad logic in m4macro code. Affects NETCONF in FreeBSD.
Here is an ut-extended test where it complained about NETCONF. Notice how /usr/local/lib are left out (because it was found there), but it seems to not find the header and the library in all the other locations: https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/426/execution/node/366/log/
Here is a test run with the changes in the attached MR that shows it has passed the NETCONF check and now complains about Kerberos: https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/ut-extended/56/flowGraphTable/kea2.1.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2048on new module revision, reinstall.sh givess error instead of upgrading2021-11-18T16:17:56ZAndrei Pavelandrei@isc.orgon new module revision, reinstall.sh givess error instead of upgradingAs the name implies, reinstall.sh was written with the idea that it can install new module versions automatically. This turned out not to be the case. `sysrepoctl -U/--update <path>` might have to be used for this purpose.
Discovered he...As the name implies, reinstall.sh was written with the idea that it can install new module versions automatically. This turned out not to be the case. `sysrepoctl -U/--update <path>` might have to be used for this purpose.
Discovered here: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1335#note_231357kea2.1-backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2047Clients are not getting the ip address2021-09-09T15:28:52ZSandeep SinghClients are not getting the ip address---
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**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea (which daemon? dhcpv4, dhcpv6, ddns, ca?) with the following config '...'
2. A client does A and sends packet B with options C,D,E via relay F that does '...'
3. The server then '...'
4. See error![IMG-20210821-WA0041](/uploads/5c0d2806b72856f9c417b6034f0c6e92/IMG-20210821-WA0041.jpg)
**Expected behavior**
A clear and concise description of what you expected to happen:
The server is supposed to send back packet A with address B assigned.
**Environment:**
- Kea version: which release? if it's compiled from git, which revision. Use kea-dhcp4 -V to find out.
- OS: [e.g. Ubuntu 16.04 x64]
- Which features were compiled in (in particular which backends)
- If/which hooks where loaded in
**Additional Information**
Add any other context about the problem here. In particular, feel free to share your config file and logs from around the time error occurred. Don't be shy to send more logs than you think are relevant. It is easy to grep large log files. It is tricky to guess what may have happened without any information.
**WE are not able to send acknowledgements to end user.**
Make sure you anonymize your config files (at the very lease make sure you obfuscate your database credentials, but you may also replace your actual IP addresses and host names with example.com and 10.0.0.0/8 or 2001:db8::/32).
**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.https://gitlab.isc.org/isc-projects/stork/-/issues/573Change sslmode based on server.env2021-11-09T14:22:02ZbradleymccandlessChange sslmode based on server.envDatabase connections are hardcoded with sslmode='disable'. We should add a variable in server.env that can change this value.Database connections are hardcoded with sslmode='disable'. We should add a variable in server.env that can change this value.1.0https://gitlab.isc.org/isc-projects/bind9/-/issues/2877v9.17 cannot be compiled on a system without libnghttp2 library2021-09-01T10:37:04ZPetr Špačekpspacek@isc.orgv9.17 cannot be compiled on a system without libnghttp2 library### Summary
main branch cannot be compiled on a system without libnghttp2 library.
### BIND version used
00c376f34d6e4732e5bb68638db7fca488ae26d1
### Steps to reproduce
1. Start with a system without libnghttp2
2. Run ./configure '-...### Summary
main branch cannot be compiled on a system without libnghttp2 library.
### BIND version used
00c376f34d6e4732e5bb68638db7fca488ae26d1
### Steps to reproduce
1. Start with a system without libnghttp2
2. Run ./configure '--disable-doh'
3. Run make
### What is the current *bug* behavior?
Compilation fails:
```
main.c:104:10: fatal error: nghttp2/nghttp2.h: No such file or directory
104 | #include <nghttp2/nghttp2.h>
```
Also, it seems that `--with-libnghttp2=no` is not implied by `--disable-doh`, but using both switches at the same time does not fix the build.
### What is the expected *correct* behavior?
Compiles and works.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrews