ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-28T14:59:24Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3296kea-dhcp4 changes filesystem access permissions on log directory2024-03-28T14:59:24ZCarsten Strotmannkea-dhcp4 changes filesystem access permissions on log directory---
name: kea-dhcp4 changes filesystem access permissions on log directory
about: Create a report to help us improve
---
**Describe the bug**
Kea-DHCP4 changes the access permissions on the directory for logfiles in the logger stateme...---
name: kea-dhcp4 changes filesystem access permissions on log directory
about: Create a report to help us improve
---
**Describe the bug**
Kea-DHCP4 changes the access permissions on the directory for logfiles in the logger statement. It removes "read" and "execute/list" (r-x) permissions for "other"
**To Reproduce**
* Change the access permissions on the log directory so that all users/processes can read/list the log directory
* Restart Kea-DHCP
* List the access permissions on the log directory. The access permissions for "other" are removed
**Expected behavior**
Kea-DHCP4 (possible other Kea processes as well) will not touch the access permissions on the log directory
**Environment:**
- Kea version:
2.4.1
tarball
linked with:
log4cplus 1.2.0
OpenSSL 1.1.1k FIPS 25 Mar 2021
database:
MySQL backend 19.0, library 10.5.5
PostgreSQL backend 18.0, library 130011
Memfile backend 3.0
- Red Hat EL 8 x86_64 (ISC Open Source Packages)
**Additional Information**
Use case: Stork agent cannot read the Kea-DHCP4 logfile in the standard configuration (as delivered in the ISC provided open source RPM packages).
This issue have been found while trying to give the stork-agent access to the Kea-DHCP4 logfile.
**Workaround:**
Change the group ownership of the logfile to group name "kea", then change the systemd-unit for "isc-stork-agent" to start the stork-agent as group "kea".
```
[Service]
Group=kea
...
```
If the removal of the access permissions for "other" is to be expected (no bug), then I recommend to adjust the stork-agent systemd unit to have stork-agent started with permissions that allow access to the Kea log files.https://gitlab.isc.org/isc-projects/bind9/-/issues/4647root "mirror" zone overrides forward zone (forward only)2024-03-22T09:42:32ZCarsten Strotmannroot "mirror" zone overrides forward zone (forward only)
### Summary
When a root zone mirror in configured in BIND 9.18.24, a forward zone (forward only) is not used.
The forward zone is for an undelegated private namespace "example.internal"
Once the root mirror is removed from the BIND ...
### Summary
When a root zone mirror in configured in BIND 9.18.24, a forward zone (forward only) is not used.
The forward zone is for an undelegated private namespace "example.internal"
Once the root mirror is removed from the BIND 9 configuration, the forward zone starts working again.
The expectation is that the forward zone is more specific, therefor it is checked first before using recursion via the root zone mirror data
### BIND version affected
```
BIND 9.18.24 (Extended Support Version) <id:6d7674f>
running on Linux x86_64 4.18.0-513.18.1.el8_9.x86_64 #1 SMP Thu Feb 1 03:51:05 EST 2024
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/scls/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/scls/isc-bind' '--sharedstatedir=/var/opt/isc/scls/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--enable-warn-error' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libxml2' '--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/opt/isc/isc-bind/root/usr/lib64' 'CPPFLAGS= -I/opt/isc/isc-bind/root/usr/include' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.18.24/sphinx/bin/sphinx-build'
compiled by GCC 8.5.0 20210514 (Red Hat 8.5.0-20)
compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
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
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/opt/isc/scls/isc-bind/named.conf
rndc configuration: /etc/opt/isc/scls/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/scls/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/scls/isc-bind/run/named/session.key
named PID file: /var/opt/isc/scls/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/scls/isc-bind/run/named/named.lock
```
### Steps to reproduce
named.conf:
```
options {
directory "/var/named";
};
zone "." {
type mirror;
file "root.zone";
};
zone "example.internal" IN {
type forward;
forwarders { 192.0.2.53; };
forward only;
};
```
Test:
```
dig @<ip-of-resolver> example.internal soa
```
will return an NXDOMAIN answer (with AD flag) from the (local) root zone
Once the Root-Mirror zone is removed, the forwarding configuration works as expected (returns the SOA record for example.internal)https://gitlab.isc.org/isc-projects/kea/-/issues/3295DDNS: addresses assigned from an arpa domain that is not configured can halt ...2024-03-28T16:58:13ZDarren AnkneyDDNS: addresses assigned from an arpa domain that is not configured can halt ddns processingKea Version tested: 2.4.0 with DHCPv4. Assumedly this same problem would exist in DHCPv6 but I didn't try that. The BIND version used in the test was 9.18.24, but I don't think it probably matters what version or brand of DNS server is...Kea Version tested: 2.4.0 with DHCPv4. Assumedly this same problem would exist in DHCPv6 but I didn't try that. The BIND version used in the test was 9.18.24, but I don't think it probably matters what version or brand of DNS server is used.
It has been discovered that it is possible that `kea-dhcp-ddns` can enter a state where no ddns updates are issued under certain circumstances. The circumstances required are only an intermittently unavailable DNS server, an address range in Kea that is not in the "reverse-ddns" portion of the DDNS configuration, a high rate of DHCP queries (I tested with 200 per second), and `"ddns-update-on-renew": true` in the `kea-dhcp4` configuration. Below is the test scenario (first with a working version of the ddns configuration):
<details><summary>Kea configuration and command line</summary>
Command: `kea-dhcp4 -c kea-dhcp4-test-ddns.json`
kea-dhcp4-test-ddns.json
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"calculate-tee-times": true,
"valid-lifetime": 7200,
"ddns-generated-prefix": "myhost",
"ddns-qualifying-suffix": "example.org",
"ddns-replace-client-name": "always",
"ddns-send-updates": true,
"ddns-override-client-update": true,
"ddns-override-no-update": true,
"ddns-update-on-renew": true,
"dhcp-ddns": {
"enable-updates": true,
"max-queue-size": 1024,
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"sender-ip": "0.0.0.0",
"sender-port": 0,
"server-ip": "127.0.0.1",
"server-port": 53001
},
"shared-networks": [
{
"name": "my-secret-lair-level-1",
"interface": "ens256",
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100-10.1.2.200"
}
]
},
{
"subnet": "172.16.0.0/24",
"id": 2,
"option-data": [
{
"name": "routers",
"data": "172.16.0.1"
}
],
"pools": [
{
"pool": "172.16.0.100-172.16.0.200"
}
]
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "DEBUG",
"debuglevel": 99,
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>BIND configuration and command line</summary>
Command: `named -4 -g -c /tmp/named.conf`
named.conf
```
options {
directory "/tmp";
recursion no;
allow-update { any;};
dnssec-validation no;
};
zone "2.1.10.in-addr.arpa" {
type primary;
file "/tmp/2.1.10.in-addr.arpa";
};
zone "0.16.172.in-addr.arpa" {
type primary;
file "/tmp/0.16.172.in-addr.arpa";
};
zone "example.org" {
type primary;
file "/tmp/example.org";
};
```
example.org
```
$ORIGIN .
$TTL 86399 ; 23 hours 59 minutes 59 seconds
example.org IN SOA ns1.example.org. hostmaster.example.org. (
1 ; serial
43200 ; refresh (12 hours)
900 ; retry (15 minutes)
1814400 ; expire (3 weeks)
7200 ; minimum (2 hours)
)
NS ns1.example.org.
ns1.example.org A 192.168.20.114
```
2.1.10.in-addr.arpa
```
$ORIGIN .
$TTL 86400 ; 1 day
2.1.10.in-addr.arpa IN SOA 2.1.10.IN-ADDR.ARPA. . (
1 ; serial
30800 ; refresh (8 hours 33 minutes 20 seconds)
7200 ; retry (2 hours)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS ns1.example.org.
```
0.16.172.in-addr.arpa
```
$ORIGIN .
$TTL 86400 ; 1 day
0.16.172.in-addr.arpa IN SOA 0.16.172.in-addr.arpa. . (
1 ; serial
30800 ; refresh (8 hours 33 minutes 20 seconds)
7200 ; retry (2 hours)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS ns1.example.org.
```
</details>
<details><summary>Working DDNS configuration and command line</summary>
Command: `kea-dhcp-ddns -c kea-dhcp-ddns-test-ddns.json`
kea-dhcp-ddns-test-ddns.json
```
{
"DhcpDdns": {
"dns-server-timeout": 40000,
"forward-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "example.org."
}
]
},
"reverse-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "2.1.10.in-addr.arpa."
},
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "0.16.172.in-addr.arpa."
}
]
},
"ip-address": "127.0.0.1",
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"port": 53001,
"loggers": [
{
"severity": "DEBUG",
"debuglevel": 99,
"name": "kea-dhcp-ddns",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>non-Working DDNS configuration and command line</summary>
Command: `kea-dhcp-ddns -c kea-dhcp-ddns-test-ddns.json`
kea-dhcp-ddns-test-ddns.json
```
{
"DhcpDdns": {
"dns-server-timeout": 40000,
"forward-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "example.org."
}
]
},
"reverse-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "2.1.10.in-addr.arpa."
}
//,
// {
// "dns-servers": [
// {
// "ip-address": "192.168.20.114",
// "port": 53
// }
// ],
// "name": "0.16.172.in-addr.arpa."
// }
]
},
"ip-address": "127.0.0.1",
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"port": 53001,
"loggers": [
{
"severity": "DEBUG",
"debuglevel": 99,
"name": "kea-dhcp-ddns",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
Perfdhcp was used to create the traffic for this test: `sudo perfdhcp -4 -r 200 -p 1800 -l ens256 -R 200`
BIND will, for some reason, stop responding intermittently during the test. The reason for that is not important for this issue. This was originally reported by a customer using some kind of off premise DNS servers that would intermittently be unavailable due to network issues. If all subnets are configured in the DDNS configuration, then DDNS will not become unresponsive when BIND becomes unresponsive.
This message might appear while BIND is unresponsive:
```DHCP_DDNS_AT_MAX_TRANSACTIONS application has 1024 queued requests but has reached maximum number of 32 concurrent transactions```
but DDNS will recover once BIND recovers.
Using the "non-Working DDNS configuration and command line", the DDNS server cannot recover and is unavailable for the remainder of the test.
The `kea-dhcp-ddns` service must be restarted before it will respond again.
I also tested this with `example.org` removed from the ddns configuration. `kea-dhcp-ddns` did not suffer a stop in processing with that zone removed. It appears to only be in the case of a missing `.arpa` zone.
<details><summary>When the `kea-dhcp-ddns` stops responding, it is during one of these failures to match reverse DNS zone</summary>
```
2024-03-19 16:56:18.347 WARN [kea-dhcp-ddns.dhcp-to-d2/1479.281473066429376] DHCP_DDNS_NO_MATCH No DNS servers match FQDN 149.0.16.172.in-addr.arpa.
2024-03-19 16:56:18.347 ERROR [kea-dhcp-ddns.dhcp-to-d2/1479.281473066429376] DHCP_DDNS_NO_REV_MATCH_ERROR Request ID 000101285974D2A2411A8BCED2CF77E9E97AD8582814F422CD88FD27E2B37B26969C5F: the configured list of reverse DDNS domains does not contain a match for: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-172-16-0-149.example.org.]
IP Address: [172.16.0.149]
DHCID: [000101285974D2A2411A8BCED2CF77E9E97AD8582814F422CD88FD27E2B37B26969C5F]
Lease Expires On: 20240319173614
Lease Length: 2400
Conflict Resolution: yes
The request has been discarded.
```
No further logs are emitted by `kea-dhcp-ddns` until the process is restarted.
</details>
<details><summary>`kea-dhcp4` does not appear to realize anything is amiss</summary>
```
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473627656064] DHCPSRV_QUEUE_NCR [hwtype=1 00:0c:01:02:03:23], cid=[01:00:0c:01:02:03:23]: Name change request to remove DNS entry queued: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173840
Lease Length: 2400
Conflict Resolution: yes
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473669656592] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173840
Lease Length: 2400
Conflict Resolution: yes
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473627656064] DHCPSRV_QUEUE_NCR [hwtype=1 00:0c:01:02:03:23], cid=[01:00:0c:01:02:03:23]: Name change request to add DNS entry queued: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173841
Lease Length: 2400
Conflict Resolution: yes
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473669656592] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173841
Lease Length: 2400
Conflict Resolution: yes
```
as the log messages appear the same whether `kea-dhcp-ddns` is doing anything or not.
</details>
[SF1804](https://isc.lightning.force.com/lightning/r/Case/500S60000074PjmIAE/view)kea2.5.8https://gitlab.isc.org/isc-projects/bind9-docker/-/issues/57Make uid/gid configurable with environment variables2024-03-20T07:11:15ZIan ChardMake uid/gid configurable with environment variablesIt would be useful if this image could use an arbitrary uid and gid (perhaps using the scheme in https://github.com/wastrachan/docker-bind).
This would make it easier to use the image with bind mounts on a host where the uid/gid of the ...It would be useful if this image could use an arbitrary uid and gid (perhaps using the scheme in https://github.com/wastrachan/docker-bind).
This would make it easier to use the image with bind mounts on a host where the uid/gid of the `bind` user are different from those inside the container.https://gitlab.isc.org/isc-projects/kea/-/issues/3294Deletion of v6 reservation over API by address causes all v6 reservations to ...2024-03-22T09:52:31ZAndrew MulheirnDeletion of v6 reservation over API by address causes all v6 reservations to disappear---
name: Deletion of v6 reservation over API by address causes all v6 reservations to disappear
about: Kea 2.4.1
---
**Describe the bug**
I am using the API to add and remove reservations for v4 and v6.
I find that removing a v4 re...---
name: Deletion of v6 reservation over API by address causes all v6 reservations to disappear
about: Kea 2.4.1
---
**Describe the bug**
I am using the API to add and remove reservations for v4 and v6.
I find that removing a v4 reservation by IP address works as expected, but removing a v6 reservation results in all reservations being deleted.
**To Reproduce**
Steps to reproduce the behavior:
1. Create two v6 reservations in the database
2. send a 'reservation-del' to the dhcp6 process via the API to remove one address
3. run a 'reservation-get-all' and receive the message ```"text": "0 IPv6 host(s) found."```
4. Perform the same sequence with v4 and it succeeds
5. Check the postgres database contents and see that the v6 reservations table is empty
Note that if I do a deletion specifying the flex-id or DUID of a reservation, only that single reservation is removed.
**Expected behavior**
I am expecting that a single IPv6 reservation is deleted.
**Environment:**
- Kea version: 2.4.1
- OS: Ubuntu 22.04.4 LTS
- Installed from kea packages on cloudsmith
- Flex-id, HA, host commands and lease commands are in use.
**Additional Information**
reservation-get-all result over api:
```
[
{
"arguments": {
"hosts": [
{
"client-classes": [],
"flex-id": "67622D6C6F6E39382D7273773030313A78652D302F302F33",
"hostname": "123123.vorboss.lab",
"ip-addresses": [
"2a00:e340:1102::3"
],
"option-data": [],
"prefixes": [
"2a00:e340:1103:300::/56"
],
"subnet-id": 1
},
{
"client-classes": [],
"flex-id": "67622D6C6F6E39382D7273773030313A78652D302F302F34",
"hostname": "123124.vorboss.lab",
"ip-addresses": [
"2a00:e340:1102::4"
],
"option-data": [],
"prefixes": [
"2a00:e340:1103:400::/56"
],
"subnet-id": 1
}
]
},
"result": 0,
"text": "2 IPv6 host(s) found."
}
]
```
Deletion sent:
```
{
"command": "reservation-del",
"service": ["dhcp6"],
"arguments": {
"subnet-id": 1,
"ip-address": "2a00:e340:1102::4"
}
}
```
Debug from kea-ctrl-agent:
```
INFO COMMAND_RECEIVED Received command 'reservation-del'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_del
INFO HOST_CMDS_RESERV_DEL reservation-del command called (parameters: { "ip-address": "2a00:e340:1102::4", "subnet-id": 1 })
INFO HOST_CMDS_RESERV_DEL_SUCCESS reservation-del command success (parameters: { "ip-address": "2a00:e340:1102::4", "subnet-id": 1 })
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on hook $reservation_del that has address 0x7ff2f67cecb0 (callout duration: 3.743 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_del (total callouts duration: 3.743 ms)
```
Subsequent reservation-get-all:
```
[
{
"arguments": {
"hosts": []
},
"result": 3,
"text": "0 IPv6 host(s) found."
}
]
```
**Contacting you**
My work email is andrew.mulheirn@vorboss.comkea2.5.8https://gitlab.isc.org/isc-projects/stork/-/issues/1335Not possible to run DHCPv6 only and collect stats with Prometheus2024-03-25T17:24:07ZRinse KloekNot possible to run DHCPv6 only and collect stats with Prometheus - Kea version: 2.4.1
- Stork: which version? 1.15.0
- OS: Debian 11
I have an issue with the prometheus exporter. I had enabled DHCPv4/DHCPv6/D2 in my kea-ctrl-agent as well as installed the KEA DHCPv4 server. However this server on... - Kea version: 2.4.1
- Stork: which version? 1.15.0
- OS: Debian 11
I have an issue with the prometheus exporter. I had enabled DHCPv4/DHCPv6/D2 in my kea-ctrl-agent as well as installed the KEA DHCPv4 server. However this server only serves DHCPv6 request. If I remove the DHCPv6/D2 entries in the Kea-ctrl-agent.conf and deinstall KEA DHCPv4 server, I am not able to see my DHCPv6 PD stats (kea_dhcp6_pd_assigned_total) anymore.
I get this error message in the log on the server
stork-agent[929757]: time="2024-03-19 11:54:23" level="error" msg="Problem parsing DHCPv4 labels from Kea: problem with content of DHCP labels response from Kea: forwarding socket is not configured for the server type dhcp4\nisc.org/stork/agent.(*SubnetList).UnmarshalJSON\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:82\nencoding/json.(*decodeState).array\n\t/builds/isc-projects/stork/tools/golang/go/src/encoding/json/decode.go:507\nencoding/json.(*decodeState).value\n\t/builds/isc-projects/stork/tools/golang/go/src/encoding/json/decode.go:364\nencoding/json.(*decodeState).unmarshal\n\t/builds/isc-projects/stork/tools/golang/go/src/encoding/json/decode.go:181\nencoding/json.Unmarshal\n\t/builds/isc-projects/stork/tools/golang/go/src/encoding/json/decode.go:108\nisc.org/stork/agent.(*lazySubnetNameLookup).fetchAndCacheNames\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:274\nisc.org/stork/agent.(*lazySubnetNameLookup).getName\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:291\nisc.org/stork/agent.(*lazySubnetNameLookup).getNameOrDefault\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:303\nisc.org/stork/agent.(*PromKeaExporter).setDaemonStats\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:772\nisc.org/stork/agent.(*PromKeaExporter).collectStats\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:877\nisc.org/stork/agent.(*PromKeaExporter).statsCollectorLoop\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:724\nruntime.goexit\n\t/builds/isc-projects/stork/tools/golang/go/src/runtime/asm_amd64.s:1650" file=" promkeaexporter.go:276 "
`
After installing the KEA DHCPv4 server again and reeneabling the KEA DHCPv4 server in kea-ctrl-agent these log message don't appear anymore and the Prometheus stats collection works again.
Is it possible to remove the DHCPv4 server and keep the stats working for DHCPv6
regads,
Rinsehttps://gitlab.isc.org/isc-projects/bind9/-/issues/4646CID 488065: Null pointer dereferences (REVERSE_INULL)2024-03-19T22:41:36ZMichal NowakCID 488065: Null pointer dereferences (REVERSE_INULL)Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROT...Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROTTL);
4802 }
4803 atomic_init(&newheader->count,
4804 atomic_fetch_add_relaxed(&init_count, 1));
>>> CID 488065: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "version" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
4805 if (version != NULL) {
4806 newheader->serial = version->serial;
4807
4808 if ((rdataset->attributes & DNS_RDATASETATTR_RESIGN) != 0) {
4809 DNS_SLABHEADER_SETATTR(newheader,
4810 DNS_SLABHEADERATTR_RESIGN);
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4645CID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", ...2024-03-19T22:41:36ZMichal NowakCID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences itCoverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 ...Coverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 changed->dirty = true;
1993 }
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1994 maybe_update_recordsandsize(false, version, header,
1995 nodename->length);
1996 }
1997 } else {
1998 /*
1999 * No non-IGNORED rdatasets of the given type exist at
/lib/dns/qpzone.c: 1972 in add()
1966 if (topheader_prev != NULL) {
1967 topheader_prev->next = newheader;
1968 } else {
1969 node->data = newheader;
1970 }
1971 newheader->next = topheader->next;
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1972 maybe_update_recordsandsize(false, version, header,
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
/lib/dns/qpzone.c: 1979 in add()
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
1978 resigninsert(qpdb, idx, newheader);
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "resigndelete", which dereferences it.
1979 resigndelete(qpdb, version,
1980 header DNS__DB_FLARG_PASS);
1981 }
1982 if (topheader_prev != NULL) {
1983 topheader_prev->next = newheader;
1984 } else {
/lib/dns/qpzone.c: 2061 in add()
2055 newheader->next = node->data;
2056 node->data = newheader;
2057 }
2058 }
2059 }
2060
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
2061 maybe_update_recordsandsize(true, version, newheader, nodename->length);
2062
2063 /*
2064 * Check if the node now contains CNAME and other data.
2065 */
2066 if (version != NULL && cname_and_other(node, version->serial)) {
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/kea/-/issues/32932.5.7 release checklist2024-03-27T15:37:01ZMarcin Godzina2.5.7 release checklist# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the actual fr...# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the actual freeze. For new stable releases or maintenance releases, please don't use the `kea-dev` build farm; use a dedicated build farm for each release cycle.
1. [x] Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html) in Jenkins for drops in performance.
1. [x] Create a Gitlab issue for bumping up library versions and `KEA_HOOKS_VERSION` and notify developers.
* In case of no developers available, it can be done by running: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that).
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. [x] If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. [x] Prepare release notes.
1. [x] Create release note on Kea GitLab wiki and notify @tomek. It should be created under the `Release-Notes` directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.3.4
1. [x] Finish release notes and conduct its review.
1. [x] Notify support that release notes are ready for review. To avoid conflicts in edits wait with next step after review is done.
1. [x] Notify @sgoldlust or @vicky that release notes are ready for review. Due to time difference please do this at least 36 hours before planned release.
1. [x] Check that packages can be uploaded to cloudsmith.
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick the latest pkg build in the `Packages` field, and the corresponding tarball build in the `Tarball` field, leave the rest as they are `PrivPubRepos: "private"`, `TarballOrPkg: "packages"`, `TestProdRepos: "testing"` and click `Build`.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) \
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 2.3.4 --repo-dir ~/isc/repos/kea/`. \
Help: `GITLAB_TOKEN='...' ./update-code-for-release.py --help`. \
The script requires an explicit flag for stable and maintenances releases e.g. `--repo-branch v2_4`. \
The script makes the following changes and actions:
1. Runs [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/prepare_kea_release.sh) that:
1. Adds release entries in ChangeLogs.
1. Updates Kea version in configure.ac.
1. Updates copyright years in files that were changed in current year.
1. Sorts message files.
1. Regenerates message files headers.
1. Regenerates parsers using Bison from Docker
1. [x] Run the script again with the `--upload-only` flag which:
1. Creates an issue in GitLab for release changes in kea repo.
1. Creates branches and merge requests for kea and kea-premium.
1. Commits the changes in both repos.
1. Checks out created branches in both repos.
1. Commits and pushes the changes to GitLab server.
1. [x] Check manually User's Guide sections:
1. [x] Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed.
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. [x] Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. [x] Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/)).
1. [x] Check and update Build Requirements.
1. [x] Check configure options against what `./configure -h` says.
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages up to date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. It's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid.
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick:
1. `rc1` if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. Submit the job that will automatically:
1. Upload the tarballs.
1. Create a GitLab issue for sanity checks, put the announcement there.
1. Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.\
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
Now it's time to publish the code.
1. [x] Update Release Notes with ChangeLog entries.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. `Kea-2.3.4`).
1. Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description:
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/).
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/).
1. [x] Upload final tarballs to repo.isc.org.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick `final`. This job will also:
- Open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org.
- Create Git tags `Kea-a.b.c` in Kea main and premium repositories.
- Create Gitlab releases `Kea-a.b.c` in Kea main and premium repositories.
1. [x] Sign tarballs with the personal key, by running [sign_kea_and_upload_asc.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh) which signs, verifies signatures and uploads them.
- If release engineer does NOT have signing key, please contact team member.
1. [x] Confirm that the tarballs have the checksums mentioned on the signing ticket.
1. [x] Wait for clearance from Security Officer to proceed with the public release (if applicable). If this is a security release, next steps will be impacted by CVE checklist.
1. [x] Login to repo.isc.org and upload final tarball to public ftp using the make-available script.
* Example command: `make-available --public --symlink=cur/2.3 /data/shared/sweng/kea/releases/2.3.4`.
* [x] For premium tarballs use `--private` option.
* For more information use `--debug` option.
* To overwrite existing content, use `--force` option.
* If you did a mistake, contact ASAP someone from the ops team to remove incorrectly uploaded tarballs.
* [x] save links to all premium tarballs and put them into signing ticket as a comment.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io:
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick your selected pkg build in the `Packages` field, the corresponding tarball build in the `Tarball` field, `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build`.
- This step also verifies sign files.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [x] Check that Docker images can be uploaded to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/).
* Make sure the right package job is selected under `Packages`.
* Tick `Upload`.
* Leave `TestProdRepos` to `testing`.
* Leave `versionTag` ticked.
* Tick `latestTag` if this is a stable or a maintenance release.
* If this is a stable or maintenance release, change `KeaDockerBranch` to the appropriate branch.
* Press `Build`.
1. [x] Build and upload Docker images to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/) with the same actions as above except change `TestProdRepos` to `production`.
1. [x] Update ReadTheDocs:
1. Trick ReadTheDocs into pulling the latest tags. Click `Build version` on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. If it's a stable release, change the default version to point to this stable release. `Admin -> Advanced Settings -> Default version* -> Kea-a.b.c`.
1. [x] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` most of the time, or
* `a.y.0-git` where `y == b + 2` if a new development series starts, or
* `x.1.0-git` where `x == a + 1` when the released minor version `b` is 9 and `a.b.c` was the last version in the development series and a new development version is coming up next.
1. [x] Contact Marketing team, and find a member who will continue work on this release:
1. [ ] Assign this ticket to person who will continue.
1. [x] Share link to signing ticket either directly or as a comment in this issue.
## Marketing
1. [x] Publish links to downloads on ISC website.
1. [ ] Update the supported versions document in the Salesforce portal (if there are stable versions released), and update the Kea document in the portal.
1. [ ] If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Verify that the KB on installing from Cloudsmith has also been updated, then update the Kea document in the SF portal and notify support customers that this new private repo exists.
1. [ ] If a new Cloudsmith repository is used, make sure that the Zapier scripts are updated.
* If those are not updated, there was an error made during preparation for new stable release. Please contact QA team and coordinate fix.
1. [x] Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
1. [x] Write release email to _kea-announce_.
1. [ ] Write email to _kea-users_ (if a major release).
1. [ ] Announce on social media.
1. [x] Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea\_(software)).
1. [ ] Write blog article (if a major release).
1. [ ] Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
1. [ ] Update Kea Premium and Kea Subscription data sheets if any new hooks.
1. [ ] Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
1. [ ] Contact Support team, find a person who will continue this release and assign this issue to them.
## Support
1. [x] Update tickets in case of waiting for support customers.
1. [ ] Close this ticketkea2.5.7https://gitlab.isc.org/isc-projects/bind9/-/issues/4644Make BIND 9.16.48 got warnings and got errors whtn configure with --enable-de...2024-03-18T03:31:51Znanwn147929@alibaba-inc.comMake BIND 9.16.48 got warnings and got errors whtn configure with --enable-developer<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
Compilation got error when configure with developer mode enabled.
### BIND version affected
BIND 9.16.48
### Steps to reproduce
1. Configure by default options `./configure`, and compile source code `make`
2. Configure by enable tests `./configure --with-cmocka --enable-developer`, and compile source code `make; make test`
### What is the current *bug* behavior?
1. Compilation by default configuration
```
base32.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:420:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, ®ion);
^
base32.c: In function ‘mem_tobuffer’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘tr’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:436:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, &tr);
^
gcc -std=gnu99 -include /home/wn147929/bind/bind-9.16.48/config.h -I/home/wn147929/bind/bind-9.16.48 -I../.. -I./unix/include -I./pthreads/include -I./include -I./include -I. -I/home/wn147929/bind/bind-9.16.48/lib/dns/include -I../../lib/dns/include -DOPENSSL_SUPPRESS_DEPRECATED -g -O2 -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -c base64.c
In file included from ./include/isc/assertions.h:21:0,
from ./include/isc/list.h:16,
from ./include/isc/types.h:32,
from ./include/isc/base64.h:20,
from base64.c:18:
base64.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
```
2. Compilation with developer mode enabled
```
base32.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: error: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Werror=address]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:420:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, ®ion);
^
base32.c: In function ‘mem_tobuffer’:
./include/isc/buffer.h:845:20: error: the comparison will always evaluate as ‘true’ for the address of ‘tr’ will never be NULL [-Werror=address]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:436:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, &tr);
^
cc1: all warnings being treated as errors
```
### What is the expected *correct* behavior?
Compile success
### Relevant configuration files
<!-- Paste any relevant configuration files here - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential issue, it is advisable to
obscure key secrets; this can be done automatically by using
`named-checkconf -px`. -->
### Relevant logs
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/64defining classes does not make them show up in ...2024-03-17T14:07:06ZDarren Ankneydefining classes does not make them show up in ...defining classes does not make them show up in ...
- no "client-classes" under "Define Host Reservations" with the initial form. New reservation forms added with the `+` do show the classes.
- "client-class" under "Define Subnets" with ...defining classes does not make them show up in ...
- no "client-classes" under "Define Host Reservations" with the initial form. New reservation forms added with the `+` do show the classes.
- "client-class" under "Define Subnets" with the initial form. New subnets added with the `+` do show the class.
Note that browser refresh adds these classes to the initial forms. May need to change how these forms are generated... This will require some thought...
No need for patch note upon fix ... this was self contained to `0.3`0.3https://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/63client-classes should allow definition of a class with no test line.2024-03-17T14:28:06ZDarren Ankneyclient-classes should allow definition of a class with no test line.See: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#reserving-client-classes-in-dhcpv4
In global client-classes as you should be able to define an client class that doesn't have a test. Then select them in the reservation. ...See: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#reserving-client-classes-in-dhcpv4
In global client-classes as you should be able to define an client class that doesn't have a test. Then select them in the reservation. Should still allow selection of client-classes that have a test inside the reservation as well, so no need to change anything inside reservations mechanism.
Won't need patch notes as is an oversight contained to the 0.3 version.0.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/62Disable output of "client-classes" in global if no classes defined2024-03-17T13:37:16ZDarren AnkneyDisable output of "client-classes" in global if no classes definedThis is placed in the configuration:
```
"client-classes": [],
```
in the global area when there are no classes defined. Stop that. It doesn't cause any problems, but it doesn't need to be there.This is placed in the configuration:
```
"client-classes": [],
```
in the global area when there are no classes defined. Stop that. It doesn't cause any problems, but it doesn't need to be there.0.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4643Properly document how the IDN arguments work2024-03-16T06:52:25ZOndřej SurýProperly document how the IDN arguments workDocument how +idn, +idnin and +idnout interact when run interactively and non-interactively.
This has changed between the version.Document how +idn, +idnin and +idnout interact when run interactively and non-interactively.
This has changed between the version.https://gitlab.isc.org/isc-projects/bind9/-/issues/4642[dig] +ednsflags do not enable EDNS2024-03-17T03:16:43ZStéphane Bortzmeyer[dig] +ednsflags do not enable EDNS### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by mak...### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by make with default
compiled by GCC 11.4.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with liburcu version: 0.13.1
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
```
### Steps to reproduce
```
dig +noedns +ednsflags=0x4000 isc.org SOA
``
### What is the current *bug* behavior?
EDNS is still disabled
### What is the expected *correct* behavior?
+ednsflags should enable EDNS, like +nsid or +dnssec do. (Or may be only if the value is not-zero.)
/label ~Bughttps://gitlab.isc.org/isc-projects/bind9/-/issues/4641dig +ednsflags does not re-enable EDNS2024-03-17T03:12:44ZMark Andrewsdig +ednsflags does not re-enable EDNS+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the same+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the sameApril 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4640Checkzone in system test leaks queries2024-03-21T02:40:22ZMark AndrewsCheckzone in system test leaks queriesThe checkzone "checking with max ttl (text)" test leaks queries.The checkzone "checking with max ttl (text)" test leaks queries.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4639Add OpenSSL Flags to proxystream_test2024-03-14T23:42:27ZSamuel ChiangAdd OpenSSL Flags to proxystream_testproxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch pr...proxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch provided below :smile:
```
diff --git a/tests/isc/Makefile.am b/tests/isc/Makefile.am
index 5cdd915..6ee1935 100644
--- a/tests/isc/Makefile.am
+++ b/tests/isc/Makefile.am
@@ -115,10 +115,12 @@ proxyheader_test_SOURCES = \
proxyheader_test_data.h
proxystream_test_CPPFLAGS = \
- $(AM_CPPFLAGS)
+ $(AM_CPPFLAGS) \
+ $(OPENSSL_CFLAGS)
proxystream_test_LDADD = \
- $(LDADD)
+ $(LDADD) \
+ $(OPENSSL_LIBS)
proxystream_test_SOURCES = \
proxystream_test.c \
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4637host, dig and nslookup don't resolve IDN domains when not used in a tty2024-03-16T06:49:38ZDirk Stöckerhost, dig and nslookup don't resolve IDN domains when not used in a tty### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve t...### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve the domain.
See also my initial bug report to perl (https://github.com/Perl/perl5/issues/22080) which points to the exact code location for this bug.
### BIND version affected
I'm using bind-utils-9.18.24-1.1.x86_64 on openSUSE Tumbleweed. Same happens on older version (Ubuntu LTS).
### Steps to reproduce
See description above
1. Call `host stöcker.eu |cat` in Linux shell
### What is the current *bug* behavior?
Does not resolve a correct name
### What is the expected *correct* behavior?
Does resolve the name whether it's a tty or not.
### Relevant configuration files
none
### Relevant logs
noneNot plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/3292kea 2.4.x: make install fails with python 3.122024-03-21T14:57:02ZNatanael Copakea 2.4.x: make install fails with python 3.12kea 2.4.1 fails to `make install` with python 3.12:
```
...
make[4]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[5]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
/bi...kea 2.4.1 fails to `make install` with python 3.12:
```
...
make[4]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[5]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
/bin/mkdir -p '/home/ncopa/aports/main/kea/pkg/kea/usr/sbin'
/bin/mkdir -p '/home/ncopa/aports/main/kea/pkg/kea/usr/lib/python3.12/site-packages/kea'
/usr/bin/install -c kea-shell '/home/ncopa/aports/main/kea/pkg/kea/usr/sbin'
/usr/bin/install -c -m 644 kea_conn.py kea_connector3.py '/home/ncopa/aports/main/kea/pkg/kea/usr/lib/python3.12/site-packages/kea'
Traceback (most recent call last):
File "<string>", line 2, in <module>
ModuleNotFoundError: No module named 'imp'
make[5]: *** [Makefile:528: install-pkgpythonPYTHON] Error 1
make[5]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[4]: *** [Makefile:740: install-am] Error 2
make[4]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[3]: *** [Makefile:577: install-recursive] Error 1
make[3]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[2]: *** [Makefile:464: install-recursive] Error 1
make[2]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin'
make[1]: *** [Makefile:462: install-recursive] Error 1
make[1]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src'
make: *** [Makefile:649: install-recursive] Error 1
```
From https://docs.python.org/3/whatsnew/3.12.html
> The asynchat, asyncore, and imp modules have been removed, along with several unittest.TestCase method aliases.