ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-11-27T00:16:10Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/217dhcrelay -6 doesn't parse -u correct when the interface name starts with t2021-11-27T00:16:10ZDaniel Loughlindhcrelay -6 doesn't parse -u correct when the interface name starts with tThe upper or -u parameter is to be formatted according to the man page: -u 2001:1:1::1%interfacename
However if the interface name begins with a t, for example -u 2001:1:1::1%team0
the %t is interpreted incorrectly resulting in the err...The upper or -u parameter is to be formatted according to the man page: -u 2001:1:1::1%interfacename
However if the interface name begins with a t, for example -u 2001:1:1::1%team0
the %t is interpreted incorrectly resulting in the error message "Interface name '2001:1:1::1/runeam0.10' too long"
It's possible to work around this issue by renaming the network adapterhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3032make doc is missing isc-logo.pdf in released archive2022-01-11T14:56:02ZPetr Menšíkmake doc is missing isc-logo.pdf in released archive<!--
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
named 9.17 tarball is missing *doc/arm/isc-logo.pdf*
### BIND version used
```
BIND 9.17.20 (Development Release) <id:642abd5>
running on Linux x86_64 5.13.12-200.fc34.x86_64 #1 SMP Wed Aug 18 13:27:18 UTC 2021
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--with-gssapi=yes' '--with-lmdb=yes' '--with-json-c' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS= -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 11.2.1 20210728 (Red Hat 11.2.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1l FIPS 24 Aug 2021
linked to OpenSSL version: OpenSSL 1.1.1l FIPS 24 Aug 2021
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.14
linked to json-c version: 0.14
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/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
- Extract archive downloaded from pages
- find -name isc-logo.pdf
- ./configure && make && make doc
### What is the current *bug* behavior?
```
...
Making doc in arm
make[2]: Entering directory '/home/pemensik/fedora/bind/bind-9.17.20/build/doc/arm'
SPHINX html-local
SPHINX pdf-local
SPHINX singlehtml
SPHINX epub
Sphinx error:
logo file 'isc-logo.pdf' does not exist
make[2]: *** [Makefile:722: pdf-local] Error 2
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/pemensik/fedora/bind/bind-9.17.20/build/doc/arm'
make[1]: *** [Makefile:442: doc-recursive] Error 1
make[1]: Leaving directory '/home/pemensik/fedora/bind/bind-9.17.20/build/doc'
make: *** [Makefile:614: doc-recursive] Error 1
```
### What is the expected *correct* behavior?
Should pass.
### Relevant configuration files
(none needed)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
Fix release scripts to include isc-logo.pdf, just as in 9.16 branch.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/218Updated bundled Bind9 to 9.11.362022-01-20T10:32:13ZPhilip PrindevilleUpdated bundled Bind9 to 9.11.36**Describe the bug**
DHCP won't build on OpenWRT due to bind/lib/isc/stats.c being broken in 9.11.14.
**To Reproduce**
Steps to reproduce the behavior:
1. Create an OpenWRT build environment (Ubuntu 20 preferred)
2. Tweak feeds/packages...**Describe the bug**
DHCP won't build on OpenWRT due to bind/lib/isc/stats.c being broken in 9.11.14.
**To Reproduce**
Steps to reproduce the behavior:
1. Create an OpenWRT build environment (Ubuntu 20 preferred)
2. Tweak feeds/packages/net/isc-dhcp/Makefile to use `PKG_VERSION:=4.4.2-P2`, `PKG_RELEASE:=1`, and the correct `PKG_HASH` for the tarball.
3. Enable `CONFIG_PACKAGE_isc-dhcp-server-ipv6=y` in your `.config` file.
4. Run `make world`
**Expected behavior**
Everything should build
**Environment:**
- ISC DHCP version: 4.4.2-P2
- OS: Ubuntu 20.04 cross-building OpenWRT `master`
- `CONFIG_PACKAGE_isc-dhcp-server-ipv6=y` enabled
**Additional Information**
Fixed with [fix variable name in conditional block](https://github.com/isc-projects/bind9/commit/261c84d91d1b4581df9f7f0ec031908299de7726) which hit v9_11_15.
**Some initial questions**
- This issue has been brought up on dhcp-workers previously but is unresolved.
**Is your feature request related to a problem? Please describe.**
Unable to build newer releases for OpenWRT (I'm the package owner on that distro).
**Describe the solution you'd like**
I'd like it to be buildable again.
**Describe alternatives you've considered**
None are applicable since they all involve applying patches to a file that gets extracted from a tarball, which isn't supported by the OpenWRT build machinery.
**Additional context**
See discussion on dhcp-workers mailing list.
**Funding its development**
I can contribute support through providing and testing the fix.
**Participating in development**
See previous.
**Contacting you**
See my gitlab account for an email address.
**UPDATE**: The original ticket was to update to 9.11.15, but the changes now update to 9.11.36.4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3035BIND with dnssec-policy stops signing when removing the ZSK key files2022-01-06T08:52:05ZThomas AmgartenBIND with dnssec-policy stops signing when removing the ZSK key files### Summary
When removing the ZSK key files from the key-directory and removing also the journal files (.signed.jnl, .jnl, .jbk), then - under certain circumstandes - BIND does create a new ZSK (after restart) but is no more able to sig...### Summary
When removing the ZSK key files from the key-directory and removing also the journal files (.signed.jnl, .jnl, .jbk), then - under certain circumstandes - BIND does create a new ZSK (after restart) but is no more able to sign the RR (neither DNSKEY-RR with the KSK nor TXT-RR with the ZSK).
### BIND version used
9.16.22, self-compiled
### Steps to reproduce
Perhaps this behavior has something to do with "**timings**" or "**timers**", because I needed to wait about one night (for ex. 8h), before I was able to reproduce the issue this morning again.
With this quick-and-dirty helperscript, I can reproduce this issue (after the mentioned timing) always:
```
#!/bin/bash
KEY_ROOT="/chroot/bind/etc/named/keys"
MASTER_DIR="/var/named/master"
[[ $# -lt 1 ]] && { echo -e "specify a zone"; exit 1; }
ZONE=$1
[[ ! -d ${KEY_ROOT}/${ZONE} ]] && { echo -e "key-dir does not exist"; exit 1; }
cd $KEY_ROOT/${ZONE}/
ZSK=$(grep -l "ZSK: yes" * | sed 's,\(.*\)\.state,\1,'g)
echo -e "ZSK found: $ZSK"
systemctl stop named
rm -f $KEY_ROOT/${ZONE}/$ZSK.*
rm -rf $MASTER_DIR/${ZONE}.hosts.*
systemctl start named
```
### What is the current *bug* behavior?
dnssec-policy is no more signing the zone, even if I run "rndc sign example.ch":
```
# No RRSIG for the DNSKEY-RR
$ dig @127.0.0.1 +short +norec +dnssec dnskey example.ch
256 3 13 yzEu6qim1W01nMHAPGhB8nXM2Qb+PTJH0c5+muyy1QjVy4+dldge0Tw6 H0rckR/sNyQOAPzpsChOqqHZhSF32w==
257 3 13 f2m47DhSRftPS7dbCw8u/C2Gnek3XJyf+FpD1gJg1dl2ZXpVVtx7RsJS ML1bq3WHrWz2IRQvW/0rsvB1f3z2WQ==
# Also no RRSIG for the TXT-Record
$ dig @127.0.0.1 +short +norec +dnssec txt example.ch
"v=spf1 -all"
```
#### rndc dnssec -status example.ch
```
$ rndc dnssec -status example.ch
dnssec-policy: thewaytogo-faster
current time: Tue Nov 30 10:09:13 2021
key: 54591 (ECDSAP256SHA256), ZSK
published: yes - since Tue Nov 30 09:59:00 2021
zone signing: no
Next rollover scheduled on Tue Dec 7 07:54:00 2021
- goal: omnipresent
- dnskey: rumoured
- zone rrsig: hidden
key: 56340 (ECDSAP256SHA256), KSK
published: yes - since Mon Nov 29 20:54:22 2021
key signing: yes - since Mon Nov 29 20:54:22 2021
No rollover scheduled
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
```
#### reloading
Reloading the zone shows (in debug-level 3) the following messages:
```
30-Nov-2021 10:05:26.927 general: info: received control channel command 'reload example.ch'
30-Nov-2021 10:05:26.927 zoneload: debug 1: zone example.ch/IN (unsigned): skipping load: master file older than last load
```
#### restarting
##### The key-files are existing (before and after restart)
```
$ ls -lahF
total 340K
drwxr-xr-x. 2 named named 4.0K 30. Nov 09:59 ./
drwxr-xr-x. 7 named named 308K 29. Nov 16:31 ../
-rw-r--r--. 1 named named 443 30. Nov 10:10 Kexample.ch.+013+54591.key
-rw-------. 1 named named 235 30. Nov 10:10 Kexample.ch.+013+54591.private
-rw-r--r--. 1 named named 541 30. Nov 10:10 Kexample.ch.+013+54591.state
-rw-r--r--. 1 named named 388 30. Nov 10:10 Kexample.ch.+013+56340.key
-rw-------. 1 named named 241 30. Nov 10:10 Kexample.ch.+013+56340.private
-rw-r--r--. 1 named named 675 30. Nov 10:10 Kexample.ch.+013+56340.state
```
```
# ZSK
$ cat Kexample.ch.+013+54591.key Kexample.ch.+013+54591.state
; This is a zone-signing key, keyid 54591, for example.ch.
; Created: 20211130085900 (Tue Nov 30 09:59:00 2021)
; Publish: 20211130085900 (Tue Nov 30 09:59:00 2021)
; Activate: 20211130085900 (Tue Nov 30 09:59:00 2021)
; Inactive: 20211207085900 (Tue Dec 7 09:59:00 2021)
; Delete: 20211217100400 (Fri Dec 17 11:04:00 2021)
example.ch. 3600 IN DNSKEY 256 3 13 yzEu6qim1W01nMHAPGhB8nXM2Qb+PTJH0c5+muyy1QjVy4+dldge0Tw6 H0rckR/sNyQOAPzpsChOqqHZhSF32w==
; This is the state of key 54591, for example.ch.
Algorithm: 13
Length: 256
Lifetime: 604800
KSK: no
ZSK: yes
Generated: 20211130085900 (Tue Nov 30 09:59:00 2021)
Published: 20211130085900 (Tue Nov 30 09:59:00 2021)
Active: 20211130085900 (Tue Nov 30 09:59:00 2021)
Retired: 20211207085900 (Tue Dec 7 09:59:00 2021)
Removed: 20211217100400 (Fri Dec 17 11:04:00 2021)
DNSKEYChange: 20211130085900 (Tue Nov 30 09:59:00 2021)
ZRRSIGChange: 20211130085900 (Tue Nov 30 09:59:00 2021)
DNSKEYState: rumoured
ZRRSIGState: hidden
GoalState: omnipresent
# KSK
$ cat Kexample.ch.+013+56340.key Kexample.ch.+013+56340.state
; This is a key-signing key, keyid 56340, for example.ch.
; Created: 20211129195422 (Mon Nov 29 20:54:22 2021)
; Publish: 20211129195422 (Mon Nov 29 20:54:22 2021)
; Activate: 20211129195422 (Mon Nov 29 20:54:22 2021)
; SyncPublish: 20211129195422 (Mon Nov 29 20:54:22 2021)
example.ch. IN DNSKEY 257 3 13 f2m47DhSRftPS7dbCw8u/C2Gnek3XJyf+FpD1gJg1dl2ZXpVVtx7RsJS ML1bq3WHrWz2IRQvW/0rsvB1f3z2WQ==
; This is the state of key 56340, for example.ch.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: no
Generated: 20211129195422 (Mon Nov 29 20:54:22 2021)
Published: 20211129195422 (Mon Nov 29 20:54:22 2021)
Active: 20211129195422 (Mon Nov 29 20:54:22 2021)
DSPublish: 20211129195759 (Mon Nov 29 20:57:59 2021)
DSRemoved: 20211129195739 (Mon Nov 29 20:57:39 2021)
PublishCDS: 20211129195422 (Mon Nov 29 20:54:22 2021)
DNSKEYChange: 20211129205955 (Mon Nov 29 21:59:55 2021)
KRRSIGChange: 20211129205955 (Mon Nov 29 21:59:55 2021)
DSChange: 20211129225759 (Mon Nov 29 23:57:59 2021)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: omnipresent
GoalState: omnipresent
```
##### Doing the restart shows the following output:
```
30-Nov-2021 10:07:04.657 general: debug 1: zone_dump: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.657 general: debug 1: zone_gotwritehandle: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.659 general: debug 3: zone_shutdown: zone example.ch/IN (signed): shutting down
30-Nov-2021 10:07:04.664 general: debug 3: zone_shutdown: zone example.ch/IN (unsigned): shutting down
30-Nov-2021 10:07:04.664 database: debug 1: calling free_rbtdb(example.ch)
30-Nov-2021 10:07:04.664 database: debug 1: done free_rbtdb(example.ch)
30-Nov-2021 10:07:04.665 general: debug 1: dump_done: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.665 general: debug 1: zone_journal_compact: zone example.ch/IN (signed): target journal size 2358
30-Nov-2021 10:07:04.665 general: debug 3: zone example.ch/IN (signed): dns_journal_compact: success
30-Nov-2021 10:07:04.669 database: debug 1: calling free_rbtdb(example.ch)
30-Nov-2021 10:07:04.669 database: debug 1: done free_rbtdb(example.ch)
30-Nov-2021 10:07:04.743 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.743 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.745 zoneload: debug 1: zone example.ch/IN (unsigned): starting load
30-Nov-2021 10:07:04.745 general: debug 1: zone_startload: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.746 zoneload: debug 2: zone example.ch/IN (unsigned): number of nodes in database: 1
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (unsigned): journal empty
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (unsigned): loaded; checking validity
30-Nov-2021 10:07:04.746 general: debug 1: dns_zone_verifydb: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.746 general: debug 1: zone_settimer: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.746 zoneload: info: zone example.ch/IN (unsigned): loaded serial 2021113001
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (signed): starting load
30-Nov-2021 10:07:04.746 general: debug 1: zone_startload: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.746 zoneload: debug 2: zone example.ch/IN (signed): number of nodes in database: 1
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (signed): journal rollforward completed successfully: up to date
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (signed): loaded; checking validity
30-Nov-2021 10:07:04.746 general: debug 1: dns_zone_verifydb: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.746 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.746 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.746 zoneload: info: zone example.ch/IN (signed): loaded serial 2021113003
30-Nov-2021 10:07:04.758 general: debug 1: dns_zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.758 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.758 general: debug 1: dns_zone_maintenance: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.758 general: debug 1: zone_settimer: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.761 general: debug 1: setnsec3param: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.761 general: debug 1: rss_post: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.761 general: debug 1: receive_secure_serial: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.764 general: error: zone example.ch/IN (signed): found no active private keys, unable to generate any signatures
30-Nov-2021 10:07:04.764 general: debug 1: zone_journal: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.769 general: debug 1: zone_needdump: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.769 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.769 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.770 general: debug 1: zone_timer: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.770 general: debug 1: zone_maintenance: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.770 general: debug 1: zone_settimer: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.771 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.771 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.771 notify: info: zone example.ch/IN (signed): sending notifies (serial 2021113004)
30-Nov-2021 10:07:04.771 dnssec: info: zone example.ch/IN (signed): reconfiguring zone keys
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: keyring: example.ch/ECDSAP256SHA256/54591 (policy thewaytogo-faster)
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: keyring: example.ch/ECDSAP256SHA256/56340 (policy thewaytogo-faster)
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: dnskeys: example.ch/ECDSAP256SHA256/54591 (policy thewaytogo-faster)
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: dnskeys: example.ch/ECDSAP256SHA256/56340 (policy thewaytogo-faster)
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) matches policy thewaytogo-faster
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) is active in policy thewaytogo-faster
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: new successor needed for DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) (policy thewaytogo-faster) in 2656704072 seconds
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) matches policy thewaytogo-faster
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) is active in policy thewaytogo-faster
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: new successor needed for DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) (policy thewaytogo-faster) in 596816 seconds
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: examine ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY in state RUMOURED
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: can we transition ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY state RUMOURED to state OMNIPRESENT?
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: dnssec evaluation of ZSK example.ch/ECDSAP256SHA256/54591 record DNSKEY: rule1=(~true or true) rule2=(~true or true) rule3=(~false or false)
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: time says no to ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY state RUMOURED to state OMNIPRESENT (wait 7016 seconds)
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: examine ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG in state HIDDEN
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: can we transition ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG state HIDDEN to state RUMOURED?
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: policy says no to ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG state HIDDEN to state RUMOURED
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type DNSKEY in state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type DNSKEY in stable state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type KRRSIG in state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type KRRSIG in stable state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type DS in state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type DS in stable state OMNIPRESENT
30-Nov-2021 10:07:04.780 general: info: CDS for key example.ch/ECDSAP256SHA256/56340 is now published
30-Nov-2021 10:07:04.780 general: info: CDNSKEY for key example.ch/ECDSAP256SHA256/56340 is now published
30-Nov-2021 10:07:04.782 general: debug 1: zone_journal: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.784 general: debug 1: zone_needdump: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.784 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.784 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.785 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.785 dnssec: debug 3: zone example.ch/IN (signed): next key event in 7016 seconds
30-Nov-2021 10:07:04.785 dnssec: info: zone example.ch/IN (signed): next key event: 30-Nov-2021 12:04:00.771
30-Nov-2021 10:07:04.785 dnssec: debug 3: zone example.ch/IN (signed): zone_rekey done: key 54591/ECDSAP256SHA256
30-Nov-2021 10:07:04.785 dnssec: debug 3: zone example.ch/IN (signed): zone_rekey done: key 56340/ECDSAP256SHA256
30-Nov-2021 10:07:04.785 general: debug 1: zone_sign: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.787 dnssec: debug 3: zone example.ch/IN (signed): zone_sign:use kasp -> yes
30-Nov-2021 10:07:04.787 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:09.771 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:09.771 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:09.771 notify: info: zone example.ch/IN (signed): sending notifies (serial 2021113005)
30-Nov-2021 10:07:09.771 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
```
#### rndc sign example.ch
```
30-Nov-2021 10:10:56.477 general: info: received control channel command 'sign example.ch'
30-Nov-2021 10:10:56.478 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.478 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.478 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.478 dnssec: info: zone example.ch/IN (signed): reconfiguring zone keys
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: keyring: example.ch/ECDSAP256SHA256/54591 (policy thewaytogo-faster)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: keyring: example.ch/ECDSAP256SHA256/56340 (policy thewaytogo-faster)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: dnskeys: example.ch/ECDSAP256SHA256/54591 (policy thewaytogo-faster)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: dnskeys: example.ch/ECDSAP256SHA256/56340 (policy thewaytogo-faster)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) matches policy thewaytogo-faster
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) is active in policy thewaytogo-faster
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: new successor needed for DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) (policy thewaytogo-faster) in 2656703840 seconds
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) matches policy thewaytogo-faster
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) is active in policy thewaytogo-faster
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: new successor needed for DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) (policy thewaytogo-faster) in 596584 seconds
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: examine ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY in state RUMOURED
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: can we transition ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY state RUMOURED to state OMNIPRESENT?
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: dnssec evaluation of ZSK example.ch/ECDSAP256SHA256/54591 record DNSKEY: rule1=(~true or true) rule2=(~true or true) rule3=(~false or false)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: time says no to ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY state RUMOURED to state OMNIPRESENT (wait 6784 seconds)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: examine ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG in state HIDDEN
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: can we transition ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG state HIDDEN to state RUMOURED?
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: policy says no to ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG state HIDDEN to state RUMOURED
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type DNSKEY in state OMNIPRESENT
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type DNSKEY in stable state OMNIPRESENT
30-Nov-2021 10:10:56.484 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type KRRSIG in state OMNIPRESENT
30-Nov-2021 10:10:56.484 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type KRRSIG in stable state OMNIPRESENT
30-Nov-2021 10:10:56.484 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type DS in state OMNIPRESENT
30-Nov-2021 10:10:56.484 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type DS in stable state OMNIPRESENT
30-Nov-2021 10:10:56.487 general: warning: zone example.ch/IN (signed): Key example.ch/ECDSAP256SHA256/56340 missing or inactive and has no replacement: retaining signatures.
30-Nov-2021 10:10:56.487 general: debug 1: zone_journal: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_needdump: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 dnssec: debug 3: zone example.ch/IN (signed): next key event in 6784 seconds
30-Nov-2021 10:10:56.490 dnssec: info: zone example.ch/IN (signed): next key event: 30-Nov-2021 12:04:00.478
30-Nov-2021 10:10:56.491 dnssec: debug 3: zone example.ch/IN (signed): zone_rekey done: key 54591/ECDSAP256SHA256
30-Nov-2021 10:10:56.491 dnssec: debug 3: zone example.ch/IN (signed): zone_rekey done: key 56340/ECDSAP256SHA256
30-Nov-2021 10:10:56.491 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.491 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.491 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.491 general: debug 1: zone_sign: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.493 dnssec: debug 3: zone example.ch/IN (signed): zone_sign:use kasp -> yes
30-Nov-2021 10:10:56.493 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
```
### What is the expected *correct* behavior?
Signed zone
### Relevant configuration files
```
# zone configuration
zone "example.ch" {
type master;
file "master/example.ch.hosts";
dnssec-policy thewaytogo-faster;
parental-agents { "ch"; };
key-directory "/etc/named/keys/example.ch";
};
```
```
# dnssec-policy
dnssec-policy "thewaytogo-faster" {
// Signatures
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
// Keys
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 30d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 7d algorithm ecdsap256sha256;
};
// Zone properties
zone-propagation-delay 300s;
max-zone-ttl 86400s;
// Parent properties
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
```January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/637Remove local_subnet and local_host relation with Kea app2022-01-03T20:51:52ZMarcin SiodelskiRemove local_subnet and local_host relation with Kea appIn #473, we changed the schema and created relations between the daemon table and the local_subnet and local_host tables. To reduce the number of changes we still keep the relation with app table, which is now redundant. We should remove...In #473, we changed the schema and created relations between the daemon table and the local_subnet and local_host tables. To reduce the number of changes we still keep the relation with app table, which is now redundant. We should remove this relation and update the queries accordingly.1.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2216Small errors in status-get command documentation2022-01-12T18:09:37ZMarcin GodzinaSmall errors in status-get command documentation16.15.19.5 in Kea documentation lacks **"packet-queue-statistics"** field in example response which is included if "multi-threading-enabled" is true.
For example we can add `"packet-queue-statistics": [ 0.0, 0.0, 0.0 ]` after `"packet-qu...16.15.19.5 in Kea documentation lacks **"packet-queue-statistics"** field in example response which is included if "multi-threading-enabled" is true.
For example we can add `"packet-queue-statistics": [ 0.0, 0.0, 0.0 ]` after `"packet-queue-size": 64`
18.3.13 in Kea documentation lists *thread-pool-size* and *packet-queue-size* being returned only when multi-threading is enabled but omits **packet-queue-statistics** in this list.
Issue applicable to dhcpv4 and dhcpv6kea2.1.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3040Removing the fetch context expiry timer uncovered latent bugs2022-01-26T11:33:40ZMichał KępieńRemoving the fetch context expiry timer uncovered latent bugsAfter the dispatch code was reworked to use netmgr, the lifetime expiry
timer for the fetch context was replaced with in-band netmgr timeouts.
Unfortunately, it turned out that the lifetime expiry timer served as a
last-resort measure fo...After the dispatch code was reworked to use netmgr, the lifetime expiry
timer for the fetch context was replaced with in-band netmgr timeouts.
Unfortunately, it turned out that the lifetime expiry timer served as a
last-resort measure for breaking various deadlocks and hangs which could
be triggered in pathological resolution scenarios (#3033 and #3037 are
examples of these).
Now that the fetches are never cleaned up after in some scenarios,
`named` may not respond at all to certain queries and hang on shutdown,
which is not acceptable for a stable release.
Since the bugs uncovered are neither new nor easy to fix, it was decided
that the lifetime expiry timer should be revived until we figure out all
known preexisting glitches in resolver code. The current plan is for
the lifetime expiry timer to be present in BIND 9.18, with the hope of
removing it before the release of BIND 9.20.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/stork/-/issues/638LDAP support2023-10-05T11:36:45ZPeter DaviesLDAP supportIs is a request for LDAP/Active Directory support in Stork
The goal is to be able to use LDAP for authenticating Stork users for now. However, in the future the scope of LDAP support will likely be expanded to cover other functionalitie...Is is a request for LDAP/Active Directory support in Stork
The goal is to be able to use LDAP for authenticating Stork users for now. However, in the future the scope of LDAP support will likely be expanded to cover other functionalities.
[RT #19920](https://support.isc.org/Ticket/Display.html?id=19920)1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/639Convert flex-id to text2022-01-13T14:24:32ZPeter DaviesConvert flex-id to textConvert flex-id to text:
This is a request to have the Kea "flex-id" value shown in plain text instead of a row of hexidecimal valuesConvert flex-id to text:
This is a request to have the Kea "flex-id" value shown in plain text instead of a row of hexidecimal values1.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/3041Decide what to do with reject-000 and other obscure options for synth-from-dn...2021-12-23T05:14:57ZPetr Špačekpspacek@isc.orgDecide what to do with reject-000 and other obscure options for synth-from-dnssec featureThe following discussions from !5446 should be addressed:
Should we have obscure options like `reject-000` and company? They were merged into 9.18.0rc1 in interest of time, so now we can discuss calmly with more time.
- [ ] @pspacek st...The following discussions from !5446 should be addressed:
Should we have obscure options like `reject-000` and company? They were merged into 9.18.0rc1 in interest of time, so now we can discuss calmly with more time.
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5446#note_251408): (+17 comments)
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5446#note_251760): (+4 comments)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/kea/-/issues/2218error in build-in help of configure script2022-01-12T14:19:35ZMarcin Godzinaerror in build-in help of configure scriptIn _./configure -h_ script, some optional packages have PATH described as optional, and some don't despite being optional.
For example:
`--with-mysql=PATH path to the MySQL 'mysql_config' script (MySQL is
...In _./configure -h_ script, some optional packages have PATH described as optional, and some don't despite being optional.
For example:
`--with-mysql=PATH path to the MySQL 'mysql_config' script (MySQL is
used for the DHCP database)`
has an optional path, but it is not described as such.
And other packages are described as optional like:
`--with-libyang[=PATH] optional path to the libyang installation directory`
I would advise checking all as if they are optional.
Kea version 2.1.1kea2.1.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/stork/-/issues/640Ability to delete Kea reservations2022-01-31T18:12:15ZTomek MrugalskiAbility to delete Kea reservationsThere's a [kea#2217](https://gitlab.isc.org/isc-projects/kea/-/issues/2217) ticket asking how to delete host reservations. The user is using Stork and sees the reservations he doesn't want to have anymore.
Once we start implementing man...There's a [kea#2217](https://gitlab.isc.org/isc-projects/kea/-/issues/2217) ticket asking how to delete host reservations. The user is using Stork and sees the reservations he doesn't want to have anymore.
Once we start implementing management capabilities, we should develop some kind of `delete` button that would remove the reservation.1.1Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/3042TCP dispatch can still hang with non-matching response2022-01-11T14:14:49ZEvan HuntTCP dispatch can still hang with non-matching responseWhile testing a fix for #3040 @michal observed another shutdown hang, which turned out to be a missed case from #3026. A TCP dispatch resumes listening after receiving a response by calling `dispatch_getnext()`, and then the response cal...While testing a fix for #3040 @michal observed another shutdown hang, which turned out to be a missed case from #3026. A TCP dispatch resumes listening after receiving a response by calling `dispatch_getnext()`, and then the response callback sees that the response didn't match the question and calls `dns_dispatch_getnext()`, which uselessly calls `dispatch_getnext()` again, bumping the dispatch reference count.
This can currently be observed with the query:
`dig @localhost -x 74.213.100.99`
The delegation to 74.in-addr.arpa is lame, all servers are responding with REFUSED. This leads to the following being logged:
```
02-Dec-2021 10:45:37.815 received packet from 24.138.252.19#53
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 19192
;; flags: qr; QUESTION: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
02-Dec-2021 10:45:37.815 DNS format error from 24.138.252.19#53 resolving 99.100.213.74.in-addr.arpa/PTR for 127.0.0.1#41988: empty question section
02-Dec-2021 10:45:37.815 fctx 0x7f30ed826000(99.100.213.74.in-addr.arpa/PTR): [result: FORMERR] response did not match question
02-Dec-2021 10:45:37.815 fctx 0x7f30ed826000(99.100.213.74.in-addr.arpa/PTR): [result: FORMERR] query canceled in rctx_done(); responding
```
It looks to me like the best fix is to make `dispatch_getnext()` idempotent.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/kea/-/issues/2219Kea ARM review, continued (stats.rst, ctrl-channel.rst, logging.rst)2021-12-08T17:49:53ZSuzanne GoldlustKea ARM review, continued (stats.rst, ctrl-channel.rst, logging.rst)Continuing review of the Kea ARMContinuing review of the Kea ARMThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3043Release Checklist for BIND 9.16.24, BIND 9.16.24-S1, 9.17.212021-12-17T13:10:01ZPetr Špačekpspacek@isc.orgRelease Checklist for BIND 9.16.24, BIND 9.16.24-S1, 9.17.21## Release Schedule
**Code Freeze:**
2021-12-01
**Tagging Deadline:**
2021-12-06
**Public Release:**
2021-12-15
## Documentation Review Links
### Release notes
- [9.17.21](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/no...## Release Schedule
**Code Freeze:**
2021-12-01
**Tagging Deadline:**
2021-12-06
**Public Release:**
2021-12-15
## Documentation Review Links
### Release notes
- [9.17.21](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/notes/notes-current.rst)
- [9.16.24](https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_16/doc/notes/notes-current.rst)
**Closed issues assigned to the milestone without a release note:**
- [9.17.21](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&state=closed&milestone_title=December%202021%20(9.16.24%2C%209.16.24-S1%2C%209.17.21)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.24](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&state=closed&milestone_title=December%202021%20(9.16.24%2C%209.16.24-S1%2C%209.17.21)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.17.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=December%202021%20(9.16.24%2C%209.16.24-S1%2C%209.17.21)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.24](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=December%202021%20(9.16.24%2C%209.16.24-S1%2C%209.17.21)¬[label_name][]=Release%20Notes&target_branch=v9_16)
### `CHANGES` entries
- [9.17.21](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/CHANGES)
- [9.16.24](https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_16/CHANGES)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=December%202021%20(9.16.24%2C%209.16.24-S1%2C%209.17.21)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.24](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=December%202021%20(9.16.24%2C%209.16.24-S1%2C%209.17.21)&label_name[]=No%20CHANGES&target_branch=v9_16)
## 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](https://gitlab.isc.org/isc-projects/bind9/-/issues/3043#note_252383) 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.
- presumably ok, @michal told me ...
- [X] ***(QA)*** Announce (on [Mattermost](https://mattermost.isc.org/isc/pl/i83nsxhyrjbripy3ehx7ctm8kr)) that the code freeze is in effect.
### 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)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** [Request signatures](https://gitlab.isc.org/isc-private/signing/-/issues/57) 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](https://gitlab.isc.org/isc-private/rpms/bind/-/pipelines/89668) 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 (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker images.
- [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 confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [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.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)2021-12-15https://gitlab.isc.org/isc-projects/kea/-/issues/2220Investigations into standardized packages2023-07-17T13:58:24ZPeter DaviesInvestigations into standardized packagesstandardized packages:
There is one notable difference between the cloudsmith Kea packages we offer.
The Ubuntu package installs Kea to run as user "_kea".
Kea installed from the rpm packages runs as root. This difference is hi...standardized packages:
There is one notable difference between the cloudsmith Kea packages we offer.
The Ubuntu package installs Kea to run as user "_kea".
Kea installed from the rpm packages runs as root. This difference is historic.
Where security policy precludes running processes as root or using sudo it may give some administrative advantage to users to be able run as a non-super-user out of the box.
Consideration must be made to users who have installed Kea already and are running it as root as are differing selinux/apparmo standard settingskea2.3.2Dan TheisenDan Theisenhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3045DiG removes underscores from queries2021-12-03T14:35:32ZtriaticDiG removes underscores from queries<!--
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
When performing a dig query on a host with an underscore in it, the underscore is unexpectedly removed.
### BIND version used
DiG 9.17.20-1+ubuntu21.10.1+isc+2-Ubuntu
### Steps to reproduce
```
dig _spf-a.microsoft.com txt
; <<>> DiG 9.17.20-1+ubuntu21.10.1+isc+2-Ubuntu <<>> _spf-a.microsoft.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 981
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;spf-a.microsoft.com. IN TXT
;; AUTHORITY SECTION:
microsoft.com. 167 IN SOA ns1-205.azure-dns.com. azuredns-hostmaster.microsoft.com. 1 3600 300 2419200 300
;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Dec 03 13:22:46 GMT 2021
;; MSG SIZE rcvd: 122
```
### What is the current *bug* behavior?
DiG removes the underscore from the host prior to the query.
### What is the expected *correct* behavior?
The query should be performed with the underscore still within the host.
nslookup for comparison:
```
nslookup -type=txt _spf-a.microsoft.com
Server: dsldevice.lan
Address: 192.168.1.254
Non-authoritative answer:
_spf-a.microsoft.com text =
"v=spf1 ip4:216.99.5.67 ip4:216.99.5.68 ip4:202.177.148.100 ip4:203.122.32.250 ip4:202.177.148.110 ip4:213.199.128.139 ip4:213.199.128.145 ip4:207.46.50.72 ip4:207.46.50.82 ip4:65.55.42.224/28 ip4:13.78.233.182 include:spf.protection.outlook.com ~all"
```https://gitlab.isc.org/isc-projects/stork/-/issues/641Rename STORK_AGENT_ADDRESS to STORK_AGENT_HOST2021-12-06T18:23:41ZMarcin SiodelskiRename STORK_AGENT_ADDRESS to STORK_AGENT_HOSTOur agent uses the `STORK_AGENT_ADDRESS` env variable to configure the address on which the agent listens. On the other hand we have `STORK_DATABASE_HOST` and `STORK_REST_HOST`. The command line switch for the agent's address is `--host`...Our agent uses the `STORK_AGENT_ADDRESS` env variable to configure the address on which the agent listens. On the other hand we have `STORK_DATABASE_HOST` and `STORK_REST_HOST`. The command line switch for the agent's address is `--host`. To be consistent we should rename it to `STORK_AGENT_HOST`.1.0Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/642Assorted ARM fixes before the 1.0 release2021-12-06T16:47:29ZMarcin SiodelskiAssorted ARM fixes before the 1.0 release2.1 Supported Systems
CentOS 7 - should be CentOS 8
macOS 10.5 - should be MacOS 11.3.1
2.3.2.3. Securing Connections
"should be readable/writable only for the user running the Stork Agent"
"should be readable/writable only BY the us...2.1 Supported Systems
CentOS 7 - should be CentOS 8
macOS 10.5 - should be MacOS 11.3.1
2.3.2.3. Securing Connections
"should be readable/writable only for the user running the Stork Agent"
"should be readable/writable only BY the user running the Stork Agent"
"All credentials must to contains the values for 4 keys"
"All credentials must contain the values for 4 keys"
"ip", "port" etc should use the `
2.3.2.10/2.3.2.11
There is an example stork-tool command line. Maybe we should add an alternative using individual switches for password, host etc. There is a known problem when someone uses an invalid URL.
2.4.3.
"There are several components of Stork". Should be: "There are two Stork components"
"By default, all components are installed to the root folder in the current directory." Should be: "By default, all components are installed IN the root folder in the current directory."
2.5. Database Migration Tool
It neglects the tool's cert-export feature.
All chapters:
We use Stork Agent, Stork agent, Stork server and Stork Server. We should probably unify.
3. Using Stork
The first sentence instructs the user to navigate to localhost:8080 without mentioning that the URL varies depending on the configuration.
3.4.2. Deleting a Machine
"The preferred way to achieve that is to issue the killall stork-agent command"
Is it really killall stork-agent?
3.5.8. Kea HA Status
The picture is heavily outdated.
3.5.6.3. Sources of Host Reservations
"This interval is currently not configurable." is not true.
7. Demo
Lacks BIND9_2 container and premium container.
7.2.1
Using kea-1-7 in the example URL for getting the token. It should rather be 2.0.1.0Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2222min-valid-lifetime and max-valid-lifetime not written by config-write2022-01-20T16:24:34ZMaria Hrabosovamin-valid-lifetime and max-valid-lifetime not written by config-writeThe min/max lifetimes in subnets are missing when the configuration is written using `config-write` management API command.
Subnet configuration tested and set using `config-test` and `config-set`:
```
{
"subnet": "192.168.0.0/24",
....The min/max lifetimes in subnets are missing when the configuration is written using `config-write` management API command.
Subnet configuration tested and set using `config-test` and `config-set`:
```
{
"subnet": "192.168.0.0/24",
...
"valid-lifetime": 3600,
"min-valid-lifetime": 3600,
"max-valid-lifetime": 3600,
}
```
Subnet configuration written using `config-write`:
```
{
"subnet": "192.168.0.0/24",
...
"valid-lifetime": 3600,
}
```
_Kea 1.9.6 on CentOS 7_kea2.1.2Francis DupontFrancis Dupont