ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-02-23T07:56:22Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1715Changes for Kea 1.9.5 release2021-02-23T07:56:22Zrelease changes scriptChanges for Kea 1.9.5 release- updated copyright years
- regenerated parsers
- regenerated message headers
- added release entry in ChangeLog
- update kea version- updated copyright years
- regenerated parsers
- regenerated message headers
- added release entry in ChangeLog
- update kea versionkea1.9.5https://gitlab.isc.org/isc-projects/bind9/-/issues/2513Random resolve problem query.c:72742021-02-22T23:02:28ZJakubRandom resolve problem query.c:7274### Summary
Random resolve problem.
### BIND version used
```
root@cnc-dns-internal-01:/var/log/named# named -V
BIND 9.16.12-Ubuntu (Stable Release) <id:aeb943d>
running on Linux x86_64 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb...### Summary
Random resolve problem.
### BIND version used
```
root@cnc-dns-internal-01:/var/log/named# named -V
BIND 9.16.12-Ubuntu (Stable Release) <id:aeb943d>
running on Linux x86_64 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/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' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-EkwSA3/bind9-9.16.12=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.38.1
linked to libuv version: 1.38.1
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
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
SYSTEM:
VERSION="20.04.2 LTS (Focal Fossa)"
```
### Steps to reproduce
This is a recursive request to translate a domain from our internal servers. This problem occurs randomly with multiple independent domains.
### What is the current *bug* behavior?
Domain is not resolve.
### What is the expected *correct* behavior?
Resolve domains correctly.
### Relevant configuration files
```
options {
listen-on port 53 { 127.0.0.1; XXX;};
directory "/var/cache/bind";
dump-file "/var/cache/bind/cache_dump.db";
statistics-file "/var/cache/bind/named.stats";
memstatistics-file "/var/cache/bind/named.mem.stats";
//dnssec-enable yes;
dnssec-validation no;
empty-zones-enable no;
allow-recursion {
XXX/16;
localhost;
};
allow-query { any; };
allow-notify { none; };
allow-update { none; };
allow-transfer { XXX; };
also-notify { XXX; };
minimal-responses yes;
notify explicit;
lame-ttl 10;
max-ncache-ttl 30;
max-cache-ttl 10;
max-cache-size 512M;
masterfile-format text; /
listen-on-v6 { none; };
};
include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { rndc-key; };
};
```
### Relevant logs and/or screenshots
```
/var/log/named/default.log.1:21-Feb-2021 13:00:13.280 client @0x7f25d0032c68 172.29.55.122#41055 (app.smartemailing.cz): query failed (failure) for app.smartemailing.cz/IN/A at query.c:7274
/var/log/named/default.log.1:21-Feb-2021 13:00:13.280 fetch completed at resolver.c:4276 for app.smartemailing.cz/A in 0.036000: failure/success [domain:smartemailing.cz,referral:0,restart:7,qrysent:6,timeout:0,lame:0,quota:0,neterr:6,badresp:0,adberr:0,findfail:0,valfail:0]
```https://gitlab.isc.org/isc-projects/kea/-/issues/1713bump up libs and hooks versions for 1.9.5 release2021-02-22T14:18:56ZMichal Nowikowskibump up libs and hooks versions for 1.9.5 releasekea1.9.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1711crash on high request rate2021-02-22T11:32:06ZAndrei Pavelandrei@isc.orgcrash on high request rateUsing forensic logging with a MySQL backend yields a segmentation fault if I send approximately 1000 requests per second with perfdhcp.
perfdhcp command:
```
perfdhcp -6 -l vethclient -R 4294967295 -r 1000 -t 1
```
This is the Kea Conf...Using forensic logging with a MySQL backend yields a segmentation fault if I send approximately 1000 requests per second with perfdhcp.
perfdhcp command:
```
perfdhcp -6 -l vethclient -R 4294967295 -r 1000 -t 1
```
This is the Kea Config I used:
<details>
<summary>kea-dhcp6.conf</summary>
<code>
{
"Dhcp6": {
"config-control": {
"config-databases": [
{
"host": "127.0.0.1",
"max-reconnect-tries": 3,
"name": "keatest",
"password": "keatest",
"port": 3306,
"reconnect-wait-time": 3000,
"type": "mysql",
"user": "keatest"
}
],
"config-fetch-wait-time": 20
},
"control-socket": {
"socket-name": "/tmp/kea-dhcp6-ctrl.sock",
"socket-type": "unix"
},
"hooks-libraries": [
{
"library": "/opt/kea/lib/kea/hooks/libdhcp_legal_log.so",
"parameters": {
"base-name": "kea-forensic6",
"type": "mysql",
"name": "keatest",
"username": "keatest",
"password": "keatest"
}
},
{
"library": "/opt/kea/lib/kea/hooks/libdhcp_cb_cmds.so"
},
{
"library": "/opt/kea/lib/kea/hooks/libdhcp_lease_cmds.so"
},
{
"library": "/opt/kea/lib/kea/hooks/libdhcp_mysql_cb.so"
},
{
"library": "/opt/kea/lib/kea/hooks/libdhcp_stat_cmds.so"
}
],
"interfaces-config": {
"interfaces": [
"vethserver"
]
},
"lease-database": {
"name": "/tmp/kea-dhcp6.csv",
"persist": false,
"type": "memfile"
},
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp6",
"output_options": [
{
"output": "stdout"
}
],
"severity": "DEBUG"
}
],
"multi-threading": {
"enable-multi-threading": true,
"thread-pool-size": 16,
"packet-queue-size": 0
},
"server-tag": "my-server",
"subnet6": [
{
"pd-pools": [
{
"delegated-len": 120,
"prefix": "2001:db8:1:0:2::",
"prefix-len": 80
}
],
"pools": [
{
"pool": "2001:db8:1:0:1::/80"
}
],
"subnet": "2001:db8:1::/64"
}
]
}
}
</code>
</details>
If I take out the `libdhcp_legal_log` hook library, the problem doesn't reproduce any more even.
The segmentation fault happened often in `StatsMgr::add()` or `IOAddress::toBytes()` but they probably have nothing to do with the actual memory corruption.
The 1000 requests per second is detrimental to reproducing this crash. Send too few and the race that probably causes this won't happen. If I send 100.000 it seems to happen less, but still happens. :shrug: This is supersistion, but I guess 1000 is close enough to Kea's limit on my machine, I get around 1% drops.
premium fix in:
https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/160
this MR needs to be backported to 1.8.xkea1.9.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/49unittest.sh fails to run on openBSD2021-02-22T11:17:06ZCurtis Blackburnunittest.sh fails to run on openBSDthe 'type' command produces different output on openBSD than on other platforms, leading the script to always behave as if the 'kyua' binary in on the PATH.
we can fix this by using 'command -v' instead of 'type'
(tested command -v on ...the 'type' command produces different output on openBSD than on other platforms, leading the script to always behave as if the 'kyua' binary in on the PATH.
we can fix this by using 'command -v' instead of 'type'
(tested command -v on openbsd, macos, centos, and solaris)BIND-9.13.0Curtis BlackburnCurtis Blackburnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2500dnssec-policy checkds does not seem to work2021-02-22T10:52:35ZMarc Dequènes (Duck)dnssec-policy checkds does not seem to workThis is a follow-up on #2488 but for a different problem.
Key 5022 is now published:
```
# rndc dnssec -status _kage.hq.duckcorp.org
dnssec-policy: generated
current time: Thu Feb 18 18:24:02 2021
key: 43281 (RSASHA512), KSK
publish...This is a follow-up on #2488 but for a different problem.
Key 5022 is now published:
```
# rndc dnssec -status _kage.hq.duckcorp.org
dnssec-policy: generated
current time: Thu Feb 18 18:24:02 2021
key: 43281 (RSASHA512), KSK
published: yes - since Fri Aug 28 00:31:44 2020
key signing: yes - since Fri Aug 28 00:31:44 2020
Rollover is due since Fri Feb 12 00:26:50 2021
- goal: hidden
- dnskey: omnipresent
- ds: unretentive
- key rrsig: omnipresent
key: 20426 (RSASHA512), ZSK
published: yes - since Sat Nov 21 00:31:44 2020
zone signing: yes - since Mon Dec 21 00:31:44 2020
Next rollover scheduled on Sat Mar 20 22:26:44 2021
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: omnipresent
key: 5022 (RSASHA512), KSK
published: yes - since Tue Feb 16 01:47:35 2021
key signing: yes - since Tue Feb 16 01:47:35 2021
Next rollover scheduled on Wed Feb 16 01:47:35 2022
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- key rrsig: omnipresent
```
I used `rndc dnssec -checkds -key 5022 published _kage.hq.duckcorp.org` yesterday right after replying to #2488 but his did not produce anything in the logs and the status is the same. The output (forgot to keep it so doing it again): `KSK 5022: Marked DS as published since 18-Feb-2021 19:48:06.000`. And I can confirm the is nothing in the logs except `received control channel command`.
I just used `rndc loadkeys _kage.hq.duckcorp.org` as suggested in #2488, so let's see if that's a similar problem.
\\_o<https://gitlab.isc.org/isc-projects/kea/-/issues/1709[percona] forensic log UTs fail because of missing primary key in logs table2021-02-19T18:53:43ZAndrei Pavelandrei@isc.org[percona] forensic log UTs fail because of missing primary key in logs table```
[ RUN ] MySqlLegalLibLoadTest.MySqlValidLoad
wipeMySQLData failed:[sh /home/andrei/work/isc/kea/src/share/database/scripts/mysql/wipe_data.sh 9.5 -N -B --user=keatest --password=keatest keatest 2>/dev/null ]
load_unload_unittest...```
[ RUN ] MySqlLegalLibLoadTest.MySqlValidLoad
wipeMySQLData failed:[sh /home/andrei/work/isc/kea/src/share/database/scripts/mysql/wipe_data.sh 9.5 -N -B --user=keatest --password=keatest keatest 2>/dev/null ]
load_unload_unittests.cc:338: Failure
Value of: HooksManager::loadLibraries(libraries)
Actual: false
Expected: true
wipeMySQLData failed:[sh /home/andrei/work/isc/kea/src/share/database/scripts/mysql/wipe_data.sh 9.5 -N -B --user=keatest --password=keatest keatest 2>/dev/null ]
[ FAILED ] MySqlLegalLibLoadTest.MySqlValidLoad (26135 ms)
```
The real problem is:
```
verbose_what_ = "unable to prepare MySQL statement <INSERT INTO logs(address, log) VALUES (?, ?)>, reason: Percona-XtraDB-Cluster prohibits use of DML comman
d on a table (keatest.logs) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER[mysql_connection.cc:337]"
```kea1.9.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1708[percona] MySqlConnectionTest.* UTs fail2021-02-19T15:04:59ZAndrei Pavelandrei@isc.org[percona] MySqlConnectionTest.* UTs fail```
[ FAILED ] 7 tests, listed below:
[ FAILED ] MySqlConnectionTest.select
[ FAILED ] MySqlConnectionTest.selectNullInteger
[ FAILED ] MySqlConnectionTest.selectNullString
[ FAILED ] MySqlConnectionTest.selectNullBlob
[ FAILE...```
[ FAILED ] 7 tests, listed below:
[ FAILED ] MySqlConnectionTest.select
[ FAILED ] MySqlConnectionTest.selectNullInteger
[ FAILED ] MySqlConnectionTest.selectNullString
[ FAILED ] MySqlConnectionTest.selectNullBlob
[ FAILED ] MySqlConnectionTest.selectNullTimestamp
[ FAILED ] MySqlConnectionTest.selectEmptyStringBlob
[ FAILED ] MySqlConnectionTest.deleteByValue
```
All of them have the same output:
```
*** ERROR: unable to open database. The test
*** environment is broken and must be fixed before
*** the MySQL tests will run correctly.
*** The reason for the problem is described in the
*** accompanying exception output.
unknown file: Failure
C++ exception with description "unable to prepare MySQL statement <DELETE FROM mysql_connection_test WHERE int_value = ?>, reason: Percona-XtraDB-Cluster prohibits use of DML command on a table (keatest.mysql_connection_test) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER" thrown in the test fixture's constructor.
```
Let's see what this means for Percona and other MySQL distributions and if we can make these tests pass for them.kea1.9.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1712ut compilation fails on freebsd2021-02-19T12:28:30ZMichal Nowikowskiut compilation fails on freebsd`ut-basic` and `ut-thread` are failing on compilcation. This is on freebsd 11.3.
logs:
- https://jenkins.isc.org/job/kea-dev/job/ut-basic/190/execution/node/181/log/
- https://jenkins.isc.org/job/kea-dev/job/ut-thread/138/execution/nod...`ut-basic` and `ut-thread` are failing on compilcation. This is on freebsd 11.3.
logs:
- https://jenkins.isc.org/job/kea-dev/job/ut-basic/190/execution/node/181/log/
- https://jenkins.isc.org/job/kea-dev/job/ut-thread/138/execution/node/38/log/
```
18:38:04.103 --- libkea_asiolink_la-process_spawn.lo ---
18:38:04.103 process_spawn.cc:265:13: error: use of undeclared identifier 'execvpe'; did you mean 'execve'?
18:38:04.103 if (execvpe(executable_.c_str(), args_.get(), vars_.get()) != 0) {
18:38:04.103 ^~~~~~~
```
the change that went into this build is #899kea1.9.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1701The ALLOC_ENGINE_V4_ALLOC_FAIL message2021-02-19T09:55:21ZPeter DaviesThe ALLOC_ENGINE_V4_ALLOC_FAIL messageAn "ALLOC_ENGINE_V4_ALLOC_FAIL" can be generated for a number of reason.
It would be helpfull and speed up problem resolution that when looking though log files that a more specific error messages or extention to this messages is gene...An "ALLOC_ENGINE_V4_ALLOC_FAIL" can be generated for a number of reason.
It would be helpfull and speed up problem resolution that when looking though log files that a more specific error messages or extention to this messages is generated.
For example:
Lease allocation timed out
No free leases on subnet X.
Free leases but not available to this client Xkea1.9.5Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2399Release Checklist for BIND 9.11.28, BIND 9.11.28-S1, BIND 9.16.12, BIND 9.16....2021-02-18T14:29:04ZMichał KępieńRelease Checklist for BIND 9.11.28, BIND 9.11.28-S1, BIND 9.16.12, BIND 9.16.12-S1, BIND 9.17.10## Release Schedule
**Code Freeze:** Wednesday, February 3rd, 2021
**Tagging Deadline:** Monday, February 8th, 2021
**Public Release:** Wednesday, February 17th, 2021
## Documentation Review Links
**Closed issues assigned to the mil...## Release Schedule
**Code Freeze:** Wednesday, February 3rd, 2021
**Tagging Deadline:** Monday, February 8th, 2021
**Public Release:** Wednesday, February 17th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.10](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.12](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
- [9.11.28](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
- [9.17.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.12](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes&target_branch=v9_16)
- [9.11.28](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.12](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)&label_name[]=No%20CHANGES&target_branch=v9_16)
- [9.11.28](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)&label_name[]=No%20CHANGES&target_branch=v9_11)
## Other Links
**QA Report:** *(not yet available)*
**Signing Ticket:** *(not yet available)*
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(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 *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition.
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize all confidential issues assigned to the release milestone and make them public.
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępień2021-02-17https://gitlab.isc.org/isc-projects/bind9/-/issues/2073dnssec-verify tries all keys which results in poor performance2021-02-17T21:37:02ZDaniel Stirnimanndnssec-verify tries all keys which results in poor performance<!--
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
I noticed that for zones with many signatures (>= ~50'000) `dnssec-verify` can perform
noticeably slower the more stand-by keys are included in the DNSKEY RR.
It looks like all ZSK keys in the DNSKEY RR are tried to verify the signatures until one is
found which succeeds. It now depends on the DNSKEY RR data structure which key is tried first and whether
the validation process is fast or slow. It would be good to first compare the RRSIG key-id with the DNSKEY key-id before attempting any cryptographic operations.
### BIND version used
dnssec-verify 9.16.5
### Steps to reproduce
````
# Create keys
# KSK
dnssec-keygen -a ECDSAP256SHA256 -f KSK foo.
Generating key pair.
Kfoo.+013+59071
# ZSK
dnssec-keygen -a ECDSAP256SHA256 foo.
Generating key pair.
Kfoo.+013+29053
# Add keys to foo.zone using an editor
$INCLUDE Kfoo.+013+59071.key
$INCLUDE Kfoo.+013+29053.key
# sign zone
dnssec-signzone -o foo. -P -t -x foo.zone Kfoo.+013+59071.private Kfoo.+013+29053.private
# verify zone
time dnssec-verify -o foo. foo.zone.signed
````
### What is the current *bug* behavior?
Depending on the key id and how many stand-by keys are present, the validation time of `dnssec-verify` slows down noticeably.
Some examples below:
**active ZSK: Kfoo.+013+39828, no stand-by ZSK**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
real 0m9.677s
user 0m9.645s
sys 0m0.026s
```
About ~9-10sec is the baseline
**active ZSK: Kfoo.+013+59286 , stand-by ZSK: Kfoo.+013+39828**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 1 stand-by, 0 revoked
real 0m9.662s
user 0m9.630s
sys 0m0.026s
```
Result is correct and within the baseline.
**active ZSK: Kfoo.+013+39828 , stand-by ZSK: Kfoo.+013+59286**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 1 stand-by, 0 revoked
real 0m14.210s
user 0m14.173s
sys 0m0.029s
```
Result is **poor**!
**active ZSK: Kfoo.+013+39828 , stand-by ZSK: Kfoo.+013+59286, Kfoo.+013+51653**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 2 stand-by, 0 revoked
real 0m18.310s
user 0m18.274s
sys 0m0.029s
```
Result is **poor**!
### What is the expected *correct* behavior?
No matter how many stand-by keys are present, the validation time is more or less constant.
### Possible fixes
Check the key id before attempting to validate each signature with each key.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/kea/-/issues/1703perfdhcp to report on the list of received leases2021-02-17T07:17:02ZAndrei Pavelandrei@isc.orgperfdhcp to report on the list of received leasesFor checking address uniqueness on a setup with shared database, it is required that perfdhcp outputs the received leases when it finishes.For checking address uniqueness on a setup with shared database, it is required that perfdhcp outputs the received leases when it finishes.kea1.9.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2402BIND 9.16.11 build fails with static OpenSSL library2021-02-16T23:38:49ZGreg RabilBIND 9.16.11 build fails with static OpenSSL libraryBuilding BIND 9.16.11 with a static version of OpenSSL fails. This worked previously with BIND 9.16.10. The problem appears to be due to the ordering of SSL libraries in several of the Makefiles. For example, this line in the 'lib/sam...Building BIND 9.16.11 with a static version of OpenSSL fails. This worked previously with BIND 9.16.10. The problem appears to be due to the ordering of SSL libraries in several of the Makefiles. For example, this line in the 'lib/samples/Makefile':
OPENSSL_LIBS = -L/opt/work6/tmp/openssl/lib -lcrypto -lssl
In BIND 9.16.10, this line read:
OPENSSL_LIBS = -L/opt/incontrol/dns/openssl/lib -lcrypto
The addition of '-lssl' must be before '-lcrypto'. However, setting OPENSSL_LIBS environment variable prior to running configure does not solve the problem because OPENSSL_LIBS does not appear to be honored for this setting.
Please find the attached config and build logs.
[bind-9.16.11-with-static-openssl-build.log](/uploads/8e027756bf75e7799fc516ef0bd88c55/bind-9.16.11-with-static-openssl-build.log)
[bind-9.16.11-with-static-openssl-config.log](/uploads/89aa076f9bf0e728820f1c6bc2d99ae4/bind-9.16.11-with-static-openssl-config.log)March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2484Add nghttp2 version to "named -V" output2021-02-16T22:45:54ZMichał KępieńAdd nghttp2 version to "named -V" outputSince BIND 9 is now requires nghttp2 for DNS-over-HTTPS (DoH) support,
`named -V` output should include:
- the nghttp2 version that `named` was built against,
- the nghttp2 version that `named` is linked to,
for consistency with th...Since BIND 9 is now requires nghttp2 for DNS-over-HTTPS (DoH) support,
`named -V` output should include:
- the nghttp2 version that `named` was built against,
- the nghttp2 version that `named` is linked to,
for consistency with the other libraries used.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/kea/-/issues/1699update syntax generated files using last bison (3.7.5)2021-02-16T16:12:04ZFrancis Dupontupdate syntax generated files using last bison (3.7.5)kea1.9.5Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/949Add the capability to convert HEX to ASCII to the forensic logging hook and o...2021-02-16T13:50:29ZCathy AlmondAdd the capability to convert HEX to ASCII to the forensic logging hook and other formatting control---
name: Add the capability to convert HEX to ASCII to the forensic logging hook as well as other formatting control
about: Suggest an idea for this project
---
As noted in [Support ticket #15209](https://support.isc.org/Ticket/Displa...---
name: Add the capability to convert HEX to ASCII to the forensic logging hook as well as other formatting control
about: Suggest an idea for this project
---
As noted in [Support ticket #15209](https://support.isc.org/Ticket/Display.html?id=15209), it would be very useful and helpful to be able to convert HEX to ASCII when logging. For example, what is being output now is:
Address: 192.168.2.10 has been renewed for 0 hrs 10 mins 0 secs to a device with hardware address: hwtype=1 f4:f2:6d:79:cb:81, client-id: 01:f4:f2:6d:79:cb:81 connected via relay at address: 192.168.3.1, identified by circuit-id: 45:53:43:44:20:65:74:68:20:31:37:2f:33:2f:32:38:2f:31:2f:31
Being able to dissect and reformat the HEX of the circuit-id would be especially helpful.
We understand that similar code already exists for reformatting HEX to ASCII in the RADIUS and flex-id hooks, hence Engineering suggested that we open this feature request.
If you'd like more examples of 'it would be really good if it looked like ....' just ask!kea1.7.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2480Feature request: signal to a secondary that received REFUSED on ixfr, to retr...2021-02-10T17:51:08ZCathy AlmondFeature request: signal to a secondary that received REFUSED on ixfr, to retry IXFR instead of AXFR on next attemptFrom [Support ticket #17554](https://support.isc.org/Ticket/Display.html?id=17554)
Use case as explained to Support:
> We have BIND transferring from a DNS device that occasionally, and temporarily, cannot provide an [AI]XFR.
> It sign...From [Support ticket #17554](https://support.isc.org/Ticket/Display.html?id=17554)
Use case as explained to Support:
> We have BIND transferring from a DNS device that occasionally, and temporarily, cannot provide an [AI]XFR.
> It signals this with a REFUSED rcode. Unfortunately when our BIND server receives this REFUSED response,
> the next XFR request is an AXFR. I understand that this is likely for compatibility reasons as some master
> may refuse an IXFR because it doesn't support it, but that is not the case here. Never mind the fact that
> one might hope to receive NOTIMP in such a case. I know that when IXFR is not available for journal reasons,
> the device is able to send AXFR as IXFR and BIND handles that perfectly fine, so I don't think its necessary
> to fail over to AXFR for the somewhat more common scenario where IXFR is not possible but AXFR is possible.
>
> Is there something that can be done on either end that would avoid this sub-optimal behaviour? Some ideas:
>
> a) Have BIND not fail over to AXFR after BIND receives a REFUSED rcode
> b) Have our device send some other rcode that BIND would not cause BIND to fail over to AXFR.
> In this case I would be looking for guidance on what RCODE we ask the device vendor to use instead.
I could envisage a configuration option for how many IXFR attempts there are on a hard fail (for some definition of 'hard fail' that includes REFUSED) before trying again with a request for an AXFR, default being 0 (which is what we do now).
I have no idea if there's a better way to handle b), although I suspect that simply just not responding would cause an IXFR retry wouldn't it?
====
This is a genuine operational problem, so suggestions for workarounds would also be much appreciated.https://gitlab.isc.org/isc-projects/kea/-/issues/1649unknown versions in config.report on Linuxes2021-02-10T15:09:48ZAndrei Pavelandrei@isc.orgunknown versions in config.report on LinuxesTwo issues cause unknown versions to appear in config.report for me:
* `$CPP` is used as the preprocessor command, but it is not a canonical, documented autoconf variable, is not used anywhere else in `configure.ac` and it evaluates to n...Two issues cause unknown versions to appear in config.report for me:
* `$CPP` is used as the preprocessor command, but it is not a canonical, documented autoconf variable, is not used anywhere else in `configure.ac` and it evaluates to nothing on some systems.
* On Linuxes that have decimal `$CXX -dumpversion` e.g. `10.2`, the `expr` used to compare versions doesn't work. You may use this script to test:
```
#!/bin/sh
if expr 10.2 \> 5 > /dev/null; then
echo it works!
else
echo something is wrong :/
fi
```
Getting rid of the backslash works on Linux, but then fails on BSDs. `test` with `-lt` just fails on both. So a portable solution has to be done.
A fix is proposed.
Before:
```
$ cat config.report | grep VERSION
CXX_VERSION: g++ (GCC) 10.2.0
PYTHON_VERSION: 3.9
BOOST_VERSION: unknown
CRYPTO_VERSION: unknown
LOG4CPLUS_VERSION: unknown
MYSQL_VERSION: 10.5.8
PGSQL_VERSION: PostgreSQL 13.1
CQL_VERSION: 2.7.1
GTEST_VERSION: unknown
```
After:
```
$ cat config.report | grep VERSION
CXX_VERSION: g++ (GCC) 10.2.0
PYTHON_VERSION: 3.9
BOOST_VERSION: 1.75
CRYPTO_VERSION: 2.17.3
LOG4CPLUS_VERSION: 2.0.5
MYSQL_VERSION: 10.5.8
PGSQL_VERSION: PostgreSQL 13.1
CQL_VERSION: 2.7.1
GTEST_VERSION: unknown
```kea1.9.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/482Failed to forward commands to rndc and server down2021-02-10T13:52:06ZglomazdovFailed to forward commands to rndc and server downinstall
https://kea.readthedocs.io/projects/Stork/en/v0.14.0/install.html#installing-on-centos-rhel-fedora
error in sh script bash.rpm.sh: dnf-plugin-config-manager rename to dnf-plugins-core
I have bind 9.16 on localhost
after instal...install
https://kea.readthedocs.io/projects/Stork/en/v0.14.0/install.html#installing-on-centos-rhel-fedora
error in sh script bash.rpm.sh: dnf-plugin-config-manager rename to dnf-plugins-core
I have bind 9.16 on localhost
after install and start server and agent:
`ERRO[2021-02-10 11:29:06] agent.go:155 Failed to forward commands to rndc: exit status 1 Address=127.0.0.1 Key= Port=953`
Server down with error: stork-server: panic: runtime error: index out of range [0] with length 0
`2021/02/10 12:43:55 http: panic serving 10.76.151.25:61933: runtime error: index out of range [0] with length 0
goroutine 61 [running]:
net/http.(*conn).serve.func1(0xc00041a000)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:1801 +0x147
panic(0xd45e20, 0xc000ae8880)
/builds/isc-projects/stork/tools/1.15.5/go/src/runtime/panic.go:975 +0x47a
isc.org/stork/server/restservice.(*RestAPI).appToRestAPI(0xc00041aa00, 0xc00041ab40, 0xc0008d65a0)
/builds/isc-projects/stork/backend/server/restservice/machines.go:471 +0x1199
isc.org/stork/server/restservice.(*RestAPI).machineToRestAPI(0xc00041aa00, 0x1, 0x1fa4190, 0xed7b58464, 0x0, 0xc000acd260, 0xc, 0x1f91, 0x8c28dc0, 0xed7b59052, ...
/builds/isc-projects/stork/backend/server/restservice/machines.go:42 +0x113
isc.org/stork/server/restservice.(*RestAPI).getMachines(0xc00041aa00, 0x0, 0x3e8, 0x0, 0x0, 0x0, 0x0, 0xc0003dc100, 0x10, 0x10)
/builds/isc-projects/stork/backend/server/restservice/machines.go:116 +0x1f8
isc.org/stork/server/restservice.(*RestAPI).GetMachines(0xc00041aa00, 0xee80a0, 0xc0004b18c0, 0xc000b2af00, 0x0, 0xc000b1f390, 0xc000b1f398, 0x0, 0x0, 0xc6b940)
/builds/isc-projects/stork/backend/server/restservice/machines.go:152 +0x3d2
isc.org/stork/server/gen/restapi.HandlerAPI.func18(0xc000b2af00, 0x0, 0xc000b1f390, 0xc000b1f398, 0x0, 0xc6b940, 0xc0003dc040, 0xc000524701, 0xc0004b17a0)
/builds/isc-projects/stork/backend/server/gen/restapi/configure_stork.go:257 +0xd6
isc.org/stork/server/gen/restapi/operations/services.GetMachinesHandlerFunc.Handle(0xc0002947c0, 0xc000b2af00, 0x0, 0xc000b1f390, 0xc000b1f398, 0x0, 0xc6b940, 0xc0
/builds/isc-projects/stork/backend/server/gen/restapi/operations/services/get_machines.go:19 +0x5e
isc.org/stork/server/gen/restapi/operations/services.(*GetMachines).ServeHTTP(0xc0005021c0, 0xee47e0, 0xc000b0d880, 0xc000b2af00)
/builds/isc-projects/stork/backend/server/gen/restapi/operations/services/get_machines.go:69 +0x2ff
github.com/go-openapi/runtime/middleware.NewOperationExecutor.func1(0xee47e0, 0xc000b0d880, 0xc000b2ad00)
/root/go/pkg/mod/github.com/go-openapi/runtime@v0.19.6/middleware/operation.go:28 +0x75
net/http.HandlerFunc.ServeHTTP(0xc000302a50, 0xee47e0, 0xc000b0d880, 0xc000b2ad00)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2042 +0x44
github.com/alexedwards/scs/v2.(*SessionManager).LoadAndSave.func1(0xee5ee0, 0xc0005a8540, 0xc0008eba00)
/root/go/pkg/mod/github.com/alexedwards/scs/v2@v2.2.0/session.go:136 +0x20f
net/http.HandlerFunc.ServeHTTP(0xc000502360, 0xee5ee0, 0xc0005a8540, 0xc0008eba00)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2042 +0x44
github.com/go-openapi/runtime/middleware.NewRouter.func1(0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/root/go/pkg/mod/github.com/go-openapi/runtime@v0.19.6/middleware/router.go:76 +0x359
net/http.HandlerFunc.ServeHTTP(0xc000652940, 0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2042 +0x44
github.com/go-openapi/runtime/middleware.Redoc.func1(0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/root/go/pkg/mod/github.com/go-openapi/runtime@v0.19.6/middleware/redoc.go:72 +0x28e
net/http.HandlerFunc.ServeHTTP(0xc000769040, 0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2042 +0x44
github.com/go-openapi/runtime/middleware.Spec.func1(0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/root/go/pkg/mod/github.com/go-openapi/runtime@v0.19.6/middleware/spec.go:46 +0x190
net/http.HandlerFunc.ServeHTTP(0xc000769080, 0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2042 +0x44
isc.org/stork/server/restservice.fileServerMiddleware.func1(0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/backend/server/restservice/middleware.go:51 +0x85
net/http.HandlerFunc.ServeHTTP(0xc000508240, 0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2042 +0x44
isc.org/stork/server/restservice.sseMiddleware.func1(0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/backend/server/restservice/middleware.go:73 +0x68
net/http.HandlerFunc.ServeHTTP(0xc000508300, 0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2042 +0x44
isc.org/stork/server/restservice.loggingMiddleware.func1(0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/backend/server/restservice/middleware.go:32 +0x336
net/http.HandlerFunc.ServeHTTP(0xc000652e60, 0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2042 +0x44
net/http.serverHandler.ServeHTTP(0xc0006c7a40, 0xee5ee0, 0xc0005a8540, 0xc0008eb800)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2843 +0xa3
net/http.(*conn).serve(0xc00041a000, 0xee7fe0, 0xc000acad40)
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:1925 +0x8ad
created by net/http.(*Server).Serve
/builds/isc-projects/stork/tools/1.15.5/go/src/net/http/server.go:2969 +0x36c
#033[36mINFO#033[0m[2021-02-10 12:43:55] machines.go:150 query machines #033[36mapp#033[0m= #033[36mlimit#033[0m=1000 #033`