ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-21T14:51:54Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3277Result YXRRSET for in Dual Stack Environment2024-03-21T14:51:54ZDavid SchmidtResult YXRRSET for in Dual Stack EnvironmentI have a Dual Stack environment with kea-dhcp4-server, kea-dhcp6-server and kea-dhcp-ddns-server.
I am running kea 2.2 on devuan 12, my source code check showed it's an issue in version 2.5.7 still.
DDNS is enabled with conflict resolu...I have a Dual Stack environment with kea-dhcp4-server, kea-dhcp6-server and kea-dhcp-ddns-server.
I am running kea 2.2 on devuan 12, my source code check showed it's an issue in version 2.5.7 still.
DDNS is enabled with conflict resolution for both kea-dhcp servers.
When the DHCP lease is released, DDNS trys to cleanup the regarding A/AAAA RRs and both PTR RRs.
When the cleanup of FwdRRSet is executed in Dual Stack environment, the RRSET cleanup of A resp. AAAA - whatever comes first - will fail with Rcode YXRRSET because the other Fwd RRSET is still there. In case of A removal, the AAAA will still be existing, in case of AAAA removal the A record will still exist. Therefore the prerequisit in buildRemoveFwdRRsRequest() neither A nor AAAA exists won't be fulfilled. This behaviour leads to corrupted PTR entries in DDNS.
To fix the issue I changed the function removingFwdRRsHandler() in src/bin/d2/nc_remove.cc to accept rcode == dns:Rcode::YXRRSET() in case of IO_COMPLETED_EVT also.
```
057 09:28:42.773 kea-dhcp-ddns.dhcp-to-d2 DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: received and queued a request.
057 09:28:42.773 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_STARTING_TRANSACTION Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5:
057 09:28:42.774 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward Add to server: 192.168.x.x port:53
057 09:28:42.787 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:42.787 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:42.787 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Reverse Replace to server: 192.168.x.x port:53
057 09:28:42.796 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:42.796 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:42.796 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [lan-client.xxx.de.]
IP Address: [192.168.x.x]
DHCID: [000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5]
Lease Expires On: 20240226094842
Lease Length: 1200
Conflict Resolution: yes
057 09:28:43.317 kea-dhcp-ddns.dhcp-to-d2 DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: received and queued a request.
057 09:28:43.317 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_STARTING_TRANSACTION Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5:
057 09:28:43.318 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward Add to server: 192.168.x.x port:53
057 09:28:43.319 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:43.320 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: YXDOMAIN
057 09:28:43.321 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward Replace to server: 192.168.x.x port:53
057 09:28:43.335 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:43.335 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:43.336 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Reverse Replace to server: 192.168.x.x port:53
057 09:28:43.344 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:43.344 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:43.344 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [lan-client.xxx.de.]
IP Address: [fdxx::282]
DHCID: [000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5]
Lease Expires On: 19700101000000
Lease Length: 2400
Conflict Resolution: yes
057 09:40:04.392 kea-dhcp-ddns.dhcp-to-d2 DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: received and queued a request.
057 09:40:04.393 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_STARTING_TRANSACTION Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5:
057 09:40:04.393 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward A/AAAA Remove to server: 192.168.x.x port:53
057 09:40:04.405 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward RR Remove to server: 192.168.x.x port:53
057 09:40:04.405 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: **YXRRSET**
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns **DHCP_DDNS_FORWARD_REMOVE_RRS_REJECTED** DNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Server, 192.168.x.x port:53, rejected a DNS update request to remove forward RR entries for FQDN, lan-client.xxx.de., with an RCODE: 7
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_REMOVE_FAILED DHCP_DDNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Transaction outcome: Status: Failed, Event: UPDATE_FAILED_EVT, Forward change: failed, Reverse change: failed, request: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [lan-client.xxx.de.]
IP Address: [fdxx::282]
DHCID: [000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5]
Lease Expires On: 20240226100843
Lease Length: 2400
Conflict Resolution: yes
```next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3276Kea primary server in "passive backup" freeze/crash on receiving ha-sync2024-03-28T10:34:28ZMarcin GodzinaKea primary server in "passive backup" freeze/crash on receiving ha-syncKea HA server set as `primary` freezes after receiving `ha-sync` command with proper arguments.
The backup server does NOT crash.
Freeze occurs only in `passive-backup` mode.
The problem exists in both v4 and v6. Also, in Memfile and m...Kea HA server set as `primary` freezes after receiving `ha-sync` command with proper arguments.
The backup server does NOT crash.
Freeze occurs only in `passive-backup` mode.
The problem exists in both v4 and v6. Also, in Memfile and mysql/psql lease database.
**Kea versions tested:**
- 2.5.7-git 8c1f22e3fb65225a0279606a8a65962850a5f881
- 2.4.0 release tarball
**Tested systems:**
- Fedora 38 in VM on my local setup.
- Ubuntu 22.04, Alpine 3.16, Fedora 36 on Jenkins build farm.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea HA servers in **Passive backup** configuration (tested configuration provided)
2. Wait for servers to connect.
3. Optionally add leases (crashes either way)
4. Send the `ha-sync` command with proper arguments to the primary server. (`"server-name": "server2"` for provided configuration) (Invalid arguments respond with error)
The primary server freezes after receiving a response to the `dhcp-disable` command, sent automatically to the backup server. It does not respond to kea-ctrl agent, keyboard interrupts or SIGHUP
<details><summary>Commands tested to freeze provided config:</summary>
```
{
command": "ha-sync",
"arguments": {
"server-name": "server2"
}
}
```
```
{
command": "ha-sync",
"arguments": {
"server-name": "server1"
}
}
```
```
{
command": "ha-sync",
"arguments": {
"server-name": "server2",
"max-period": 60
}
}
```
</details>
**Configuration**
<details><summary>Primary</summary>
```
{
"Dhcp4": {
"option-data": [],
"hooks-libraries": [
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"peers": [
{
"auto-failover": true,
"name": "server1",
"role": "primary",
"url": "http://192.168.56.102:8003/"
},
{
"auto-failover": true,
"name": "server2",
"role": "backup",
"url": "http://192.168.56.103:8003/"
}
],
"state-machine": {
"states": []
},
"mode": "passive-backup",
"this-server-name": "server1",
"multi-threading": {
"enable-multi-threading": true,
"http-dedicated-listener": true,
"http-listener-threads": 0,
"http-client-threads": 0
}
}
]
}
},
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"shared-networks": [],
"subnet4": [
{
"subnet": "192.168.50.0/24",
"pools": [
{
"pool": "192.168.50.1-192.168.50.200"
}
],
"interface": "enp0s9"
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/home/mgodzina/installed/keadev/var/run/kea/control_socket"
},
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 4000,
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "/home/mgodzina/installed/keadev/var/log/kea.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"lease-database": {
"type": "memfile"
}
}
}
```
</details>
<details><summary>Backup</summary>
```
{
"Dhcp4": {
"option-data": [],
"hooks-libraries": [
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"peers": [
{
"auto-failover": true,
"name": "server1",
"role": "primary",
"url": "http://192.168.56.102:8003/"
},
{
"auto-failover": true,
"name": "server2",
"role": "backup",
"url": "http://192.168.56.103:8003/"
}
],
"state-machine": {
"states": []
},
"mode": "passive-backup",
"this-server-name": "server2",
"multi-threading": {
"enable-multi-threading": true,
"http-dedicated-listener": true,
"http-listener-threads": 0,
"http-client-threads": 0
}
}
]
}
},
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"shared-networks": [],
"subnet4": [
{
"subnet": "192.168.50.0/24",
"pools": [
{
"pool": "192.168.50.1-192.168.50.200"
}
],
"interface": "enp0s9"
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/home/mgodzina/installed/keadev/var/run/kea/control_socket"
},
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 4000,
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "/home/mgodzina/installed/keadev/var/log/kea.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"lease-database": {
"type": "memfile"
}
}
}
```
</details>
**Logs**
<details><summary>Primary server log tail</summary>
```
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.commands/2096.139741364354944] COMMAND_SOCKET_CONNECTION_OPENED Opened socket 38 for incoming command connection
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.commands/2096.139741364354944] COMMAND_SOCKET_READ Received 127 bytes over command socket 38
2024-02-28 16:20:13.417 INFO [kea-dhcp4.commands/2096.139741364354944] COMMAND_RECEIVED Received command 'ha-sync'
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.callouts/2096.139741364354944] HOOKS_CALLOUTS_BEGIN begin all callouts for hook $ha_sync
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_CLIENT_REQUEST_SEND sending HTTP request POST / HTTP/1.1 to http://192.168.56.103:8003/
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_CLIENT_REQUEST_SEND_DETAILS detailed information about request sent to http://192.168.56.103:8003/:
POST / HTTP/1.1
Host: 192.168.56.103
Content-Length: 86
Content-Type: application/json
{ "arguments": { "origin": 2000 }, "command": "dhcp-disable", "service": [ "dhcp4" ] }
2024-02-28 16:20:13.417 INFO [kea-dhcp4.ha-hooks/2096.139741364354944] HA_SYNC_START server1: starting lease database synchronization with server2
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_SERVER_RESPONSE_RECEIVED received HTTP response from http://192.168.56.103:8003/
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_SERVER_RESPONSE_RECEIVED_DETAILS detailed information about well-formed response received from http://192.168.56.103:8003/:
HTTP/1.1 200 OK
Content-Length: 54
Content-Type: application/json
Date: Wed, 28 Feb 2024 15:20:13 GMT
[ { "result": 0, "text": "DHCPv4 service disabled" } ]
```
</details>
<details><summary>Backup server log snippet with timeout:</summary>
```
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_REQUEST_RECEIVE_START start receiving request from 192.168.56.102 with timeout 10
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_DATA_RECEIVED received 179 bytes from 192.168.56.102
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_CLIENT_REQUEST_RECEIVED received HTTP request from 192.168.56.102
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_CLIENT_REQUEST_RECEIVED_DETAILS detailed information about well-formed request received from 192.168.56.102:
POST / HTTP/1.1
Host: 192.168.56.103
Content-Length: 86
Content-Type: application/json
{ "arguments": { "origin": 2000 }, "command": "dhcp-disable", "service": [ "dhcp4" ] }
2024-02-28 16:20:13.413 INFO [kea-dhcp4.commands/20519.140151306917568] COMMAND_RECEIVED Received command 'dhcp-disable'
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.callouts/20519.140151306917568] HOOKS_CALLOUTS_BEGIN begin all callouts for hook command_processed
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.callouts/20519.140151306917568] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook command_processed that has address 0x7f778767ffe0 (callout duration: 0.000 ms)
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.callouts/20519.140151306917568] HOOKS_CALLOUTS_COMPLETE completed callouts for hook command_processed (total callouts duration: 0.000 ms)
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_SERVER_RESPONSE_SEND sending HTTP response HTTP/1.1 200 OK to 192.168.56.102
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_SERVER_RESPONSE_SEND_DETAILS detailed information about response sent to 192.168.56.102:
HTTP/1.1 200 OK
Content-Length: 54
Content-Type: application/json
Date: Wed, 28 Feb 2024 15:20:13 GMT
[ { "result": 0, "text": "DHCPv4 service disabled" } ]
2024-02-28 16:20:17.831 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2024-02-28 16:20:17.831 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2024-02-28 16:20:17.831 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2024-02-28 16:20:17.832 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.033 ms
2024-02-28 16:20:17.832 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2024-02-28 16:20:17.832 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: flush-reclaimed-leases
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than 3600 seconds ago
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than 3600 seconds ago
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0 expired-reclaimed leases
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: flush-reclaimed-leases
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.032 ms
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2024-02-28 16:20:37.891 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.027 ms
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2024-02-28 16:20:43.433 DEBUG [kea-dhcp4.http/20519.140151315310272] HTTP_IDLE_CONNECTION_TIMEOUT_OCCURRED closing persistent connection with 192.168.56.102 as a result of a timeout
2024-02-28 16:20:43.433 DEBUG [kea-dhcp4.http/20519.140151315310272] HTTP_CONNECTION_STOP stopping HTTP connection from 192.168.56.102
```
</details>
[gdb.txt](/uploads/de79e56462885f7947eab90267f7a658/gdb.txt)kea2.5.8Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4613Release Checklist for BIND 9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.222024-03-27T21:12:56ZPetr Špačekpspacek@isc.orgRelease Checklist for BIND 9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22## Release Schedule
**Code Freeze:** Wednesday, 6 March 2024
**Tagging Deadline:** Monday, 11 March 2024
**Public Release:** Wednesday, 20 March 2024
## Warning
This release uses non-standard process. It is based on February releas...## Release Schedule
**Code Freeze:** Wednesday, 6 March 2024
**Tagging Deadline:** Monday, 11 March 2024
**Public Release:** Wednesday, 20 March 2024
## Warning
This release uses non-standard process. It is based on February releases (9.16.48, 9.18.24, 9.19.21) and adds cherry-picked MRs on top.
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.16.49](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
- [9.16.49-S1](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16-S)
- [9.18.25](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.18.25-S1](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18-S)
- [9.19.22](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
**Merge requests merged into the milestone without a release note:**
- [9.16.49](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16)
- [9.16.49-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16-sub)
- [9.18.25](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18)
- [9.18.25-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18-sub)
- [9.19.22](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=main)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.16.49](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16)
- [9.16.49-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16-sub)
- [9.18.25](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18)
- [9.18.25-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18-sub)
- [9.19.22](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=main)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Rebase -S editions on top of current open-source versions: `git checkout bind-9.18-sub && git rebase origin/bind-9.18`
- [x] ***(QA)*** [Inform](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_supp_marketing.py) Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform. Check [public](https://gitlab.isc.org/isc-projects/bind9/-/pipelines?scope=all&source=schedule) and [private](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=all&source=schedule) scheduled pipelines.
- [x] ***(QA)*** Check charts from `shotgun:*` jobs in the scheduled pipelines to verify there is no unexplained performance drop for any protocol.
- [x] ***(QA)*** Check [Perflab](https://perflab.isc.org/) 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](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/)[^1] (Subscription Edition only).
- [x] ***(QA)*** [Ensure](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/check_backports.py) all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** ~~[Announce](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_code_freeze.py) (on Mattermost) that the code freeze is in effect.~~
### Before the Tagging Deadline
- [x] ***(QA)*** Inspect the current output of the `cross-version-config-tests` job to verify that no unexpected backward-incompatible change was introduced in the current release cycle.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well. [Example](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/510)
- [x] ***(QA)*** Add a release marker to `CHANGES`. Examples: [9.18](https://gitlab.isc.org/isc-projects/bind9/-/commit/f14d8ad78c0506fd4247187f2177f8eceeb6b3b9), [9.16](https://gitlab.isc.org/isc-projects/bind9/-/commit/1bcdf21874f99a00da389d723e0ad07dfd70f9f1)
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only). [Example](https://gitlab.isc.org/isc-private/bind9/-/commit/0f03d5737bcbdaa1bf713c6db1887b14938c3421)
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` ([9.18+](https://gitlab.isc.org/isc-projects/bind9/-/commit/3c85ab7f4c35e6d8acef1393606002a0a8730100)) or `version` ([9.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7692/diffs?commit_id=1bcdf21874f99a00da389d723e0ad07dfd70f9f1)).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [x] ***(QA)*** ~~Update GitLab settings for all maintained branches to disallow merging to them: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)~~
- [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)*** Check that the formatting is correct for the HTML version of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Verify GitLab CI results [for the tags](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=tags) created and sign off on the releases to be published.
- [x] ***(QA)*** ~~Update GitLab settings for all maintained branches to allow merging to them again: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)~~
- [x] ***(QA)*** Prepare (using [`version_bump.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/version_bump.py)) and merge MRs resetting the release notes and updating the version string for [each](!8856) [maintained](!8857) [branch](!8858).
- [x] ***(QA)*** Rebase the Subscription Edition branches (including recent release prep commits) on top of the open source branches with updated version strings.
- [x] ***(QA)*** [Announce (on Mattermost) that the code freeze is over.](https://mattermost.isc.org/isc/pl/8chqbcam7igq5nu8ryxtrjfq4r)
- [x] ***(QA)*** [Request signatures for the tarballs, providing their location and checksums. Ask signers on Mattermost.](https://mattermost.isc.org/isc/pl/ku6mfsqaktrq3ryz4iuth8183c)
- [x] ***(Signers)*** Ensure that the contents of tarballs and tags are identical.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again: Run `publish_bind.sh` on repo.isc.org to pre-publish.
- [x] ***(QA)*** ~~Prepare the `patches/` subdirectory for each security release (if applicable).~~
- [x] ***(QA)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages (in [cloudsmith branch in private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith)). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/e2512f4cfaf991827a635e374e7e93b27a5f38ba)
- [x] ***(Marketing)*** ~~Prepare and send out ASN emails (as outlined in the CVE checklist; if applicable).~~
### On the Day of Public Release
- [x] ***(QA)*** ~~Wait for clearance from Security Officer to proceed with the public release (if applicable).~~
- [x] ***(QA)*** Place tarballs in public location on FTP site.
- [x] ***(QA)*** Inform Marketing of the release, providing FTP links for the published tarballs.
- [x] ***(QA)*** [Use the Printing Press project to prepare a release announcement email.](isc-private/printing-press!103)
- [x] ***(Marketing)*** Publish links to downloads on ISC website. [Example](https://gitlab.isc.org/website/theme-staging-site/-/commit/1ac7b30b73cb03228df4cd5651fa4e774ac35625)
- [x] ***(Marketing)*** Update the BIND -S information document in SF with download links to the new versions. (If this is a security release, this will have already been done as part of the ASN process.)
- [x] ***(Marketing)*** Update the Current Software Versions document in the SF portal if any stable versions were released.
- [x] ***(Marketing)*** Send the release announcement email to the *bind-announce* mailing list (and to *bind-users* if a major release - [example](https://lists.isc.org/pipermail/bind-users/2022-January/105624.html)).
- [x] ***(Marketing)*** Announce release on social media sites.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Support)*** Add the new releases to the [vulnerability matrix in the Knowledge Base](https://kb.isc.org/docs/aa-00913).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages in [private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/2007d566db81dd9dfd79e571e2f600a3bc284da4)
- [x] ***(QA)*** Build [public RPMs](https://gitlab.isc.org/isc-packages/rpms/bind). [Example commit](https://gitlab.isc.org/isc-packages/rpms/bind/-/commit/3b5e851ea7c4e3570371a4878b5461f02a44f8cc) which triggers [Copr builds](https://copr.fedorainfracloud.org/coprs/isc/) automatically
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker files [here](https://gitlab.isc.org/isc-projects/bind9-docker/-/branches) and make sure push is synchronized to [GitHub](https://github.com/isc-projects/bind9-docker). [Docker Hub](https://hub.docker.com/r/internetsystemsconsortium/bind9) should pick it up automatically. [Example](https://gitlab.isc.org/isc-projects/bind9-docker/-/commit/cada7e10e9af951595c98bfffc4bd42512faac05)
- [x] ***(QA)*** Ensure all new tags are annotated and signed. `git show --show-signature v9.19.12`
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Using [`merge_tag.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/merge_tag.py), merge published release tags back into the their relevant development/maintenance branches.
- [x] ***(QA)*** ~~Ensure `allow_failure: true` is removed from the `cross-version-config-tests` job if it was set during the current release cycle.~~
- [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](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=milestone_due_desc&state=opened&confidential=yes) 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. Black, PyLint, Sphinx) by modifying the relevant `Dockerfile`.](isc-projects/images!305)
- [x] ***(QA)*** [Run a pipeline to rebuild all images used in GitLab CI.](https://gitlab.isc.org/isc-projects/images/-/pipelines/168133)
- [x] ***(QA)*** [Update `metadata.json` with the upcoming release information.](isc-private/bind-qa!96)
[^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.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4612resolver crashes on 10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS...2024-03-06T00:16:14ZPetr Špačekpspacek@isc.orgresolver crashes on 10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS query### Summary
Processing query `10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS` causes the resolver to crash.
### BIND version affected
* ~"Affects v9.19": 88c56e25a1e6c0c994f38a5db4c6b6f677ec633a
It seems it does NOT affect ...### Summary
Processing query `10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS` causes the resolver to crash.
### BIND version affected
* ~"Affects v9.19": 88c56e25a1e6c0c994f38a5db4c6b6f677ec633a
It seems it does NOT affect stable branches.
### Steps to reproduce
1. `named -g -c /dev/null`
2. `dig @127.0.0.1 10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS`
3. :boom:
### What is the current *bug* behavior?
```
28-Feb-2024 14:35:04.363 chase DS servers resolving '10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct/DS/IN': 18.202.136.15#53
28-Feb-2024 14:35:04.466 resolver.c:10427: REQUIRE(!dns_rdataset_isassociated(rdataset)) failed
```
### What is the expected *correct* behavior?
No crash.
### Relevant logs
- [Debug -d 99 log](/uploads/7aeca53fc41d38c9c9cbfa8dac8b3475/log)March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4611Stub zones return unexpected NS records2024-03-06T00:14:18ZPeter DaviesStub zones return unexpected NS records### Summary
BIND server B with a static-stub zone configured with a server address of BIND
server A, a secondary for that zone, may return unexpected NS records.
### BIND version affected
```
I tested with BIND 9.19.21, but I belie...### Summary
BIND server B with a static-stub zone configured with a server address of BIND
server A, a secondary for that zone, may return unexpected NS records.
### BIND version affected
```
I tested with BIND 9.19.21, but I believe this behaviour probably goes back to BIND 9.11.x
named -V
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023
built by make with '--enable-fixed-rrset' '--enable-dnstap' '--enable-querytrace=yes' '--with-openssl' '--with-libxml2' '--with-json-c' '--enable-full-report' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/'
compiled by GCC 12.3.1 20230508 (Red Hat 12.3.1-1)
compiled with OpenSSL version: OpenSSL 3.0.9 30 May 2023
linked to OpenSSL version: OpenSSL 3.0.9 30 May 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.46.0
compiled with liburcu version: 0.15.0-pre
compiled with jemalloc version: 5.2.1
compiled with libnghttp2 version: 1.51.0
linked to libnghttp2 version: 1.51.0
compiled with libxml2 version: 2.10.3
linked to libxml2 version: 21004
compiled with json-c version: 0.15
linked to json-c version: 0.17
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
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): no
TKEY mode 3 support (GSS-API): yes
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
1) set up servers A and B with the configurations below.
2) Query Server B repeatedly for an RR from the static-stub zone:
```
While true do dig hgw.ddi.com @127.0.0.1
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27748
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 23cb1ccef98f3bf00100000065df1c8b908417789e893016 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 300 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 260 IN NS bialistock.ddi.com.
ddi.com. 260 IN NS haparanda.ddi.com.
;; ADDITIONAL SECTION:
haparanda.ddi.com. 300 IN A 10.0.0.237
bialistock.ddi.com. 300 IN A 10.0.0.49
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 11:44:11 UTC 2024
;; MSG SIZE rcvd: 165
```
### What is the current *bug* behavior?
When the NS records in the authority section expire, Server B add the server-names
from its static-stub configuration as NS records plus a NS record in the name of
the domain itself
```
...
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50265
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 88424ea83ed9b09d0100000065df1d8b76b871a0c1e4d1e7 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 44 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 4 IN NS bialistock.ddi.com.
ddi.com. 4 IN NS haparanda.ddi.com.
;; ADDITIONAL SECTION:
haparanda.ddi.com. 44 IN A 10.0.0.237
bialistock.ddi.com. 44 IN A 10.0.0.49
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 11:48:27 UTC 2024
;; MSG SIZE rcvd: 165
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39703
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 329a1ed8e54b28d30100000065df1d90545987c64fe602f2 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 39 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 86400 IN NS StaticStubZoneNS-1.org.
ddi.com. 86400 IN NS ddi.com.
ddi.com. 86400 IN NS StaticStubZoneNS-2.org.
```
### What is the expected *correct* behavior?
I expect to see the NS records from the domain or none at all.
### Relevant configuration files
Server A config:
```
options {
directory "/home/named";
pid-file "named.pid";
listen-on-v6 { none; };
dnssec-validation auto;
recursion yes;
allow-recursion { any; };
};
zone "ddi.com" IN {
type secondary;
primaries { 10.0.0.4;};
file "s/db.ddi.com";
allow-transfer {any;};
notify false;
};
```
Server B config:
```
options {
directory "/home/named";
pid-file "named.pid";
listen-on-v6 { none; };
dnssec-validation no;
minimal-responses no;
recursion yes;
max-cache-size 90%;
allow-recursion { any; };
};
zone "ddi.com" IN {
type static-stub;
server-addresses {
10.0.0.182;
};
server-names {
"StaticStubZoneNS-1.org";
"StaticStubZoneNS-2.org";
};
};
```
Zone file:
```
ddi.com. 86400 IN SOA haparanda.ddi.com. support.ddi.com. 2024021733 1800 900 604800 86400
ddi.com. 260 IN NS haparanda.ddi.com.
ddi.com. 260 IN NS bialistock.ddi.com.
alice-laptop.ddi.com. 600 IN A 10.0.0.149
bag-local-lyset.ddi.com. 300 IN A 10.0.0.15
bialistock.ddi.com. 300 IN A 10.0.0.49
haparanda.ddi.com. 300 IN A 10.0.0.237
hgw.ddi.com. 300 IN A 10.0.0.1
...
```
### Relevant logs
Server B has no IPV6 connectivity the following was logged at startup:
```
Feb 28 11:44:11 bialistock named[235198]: network unreachable resolving 'StaticStubZoneNS-1.org/AAAA/IN': 2001:500:c::1#53
Feb 28 11:44:11 bialistock named[235198]: network unreachable resolving 'StaticStubZoneNS-2.org/A/IN': 2001:500:c::1#53
```
[SF00001680](https://isc.lightning.force.com/lightning/r/Case/500S60000054BVSIA2/view)https://gitlab.isc.org/isc-projects/kea/-/issues/3275Kea DB allows to store too short identifier in the lease table2024-03-21T14:50:56ZSlawek FigielKea DB allows to store too short identifier in the lease tableWhile performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it b...While performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it blocks fetching this lease by API. I don't know if it has any other internal consequences.
Steps to reproduce:
1. Setup Kea 2.3.8 or above with PostgreSQL.
2. Configure lease database.
3. Insert a lease with too short DUID (e.g., `00`)
```
INSERT INTO lease6(address, duid, valid_lifetime, expire, subnet_id, pref_lifetime, lease_type, iaid, prefix_len, hwtype, hwaddr_source, state) VALUES('3001:db8:1::2', DECODE('00', 'hex'), 3600, NOW() + interval '1' MONTH, 1, 1800, 0, 1, 128, 0, 0, 1);
```
4. Send the `lease-get` command with the specified address (i.e., `3001:db8:1::2`).
5. Observe the error:
```
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command lease6-get received from remote address 127.0.0.1
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | ERROR LEASE_CMDS_GET6_FAILED lease6-get command failed (parameters: { "ip-address": "3001:db8:1::2", "type": "IA_NA" }, reason: Could not convert data to Lease6, reason: identifier is too short (1), at least 3 is required)
stork-agent-kea6-1 | ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $lease6_get registered by library with index 1 (callout address 0x7f12e8310e90) (callout duration 0.593 ms)
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_FORWARDED command lease6-get successfully forwarded to the service dhcp6 from remote address 127.0.0.1
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3274Synchronous run script2024-03-14T14:37:11ZAndrei Pavelandrei@isc.orgSynchronous run scriptAs ARM states
> Currently, enabling synchronous calls to external scripts is not supported.
Sync run script is not supported.
With the addition of sync process spawn functionality in issue 3025, this is now doable.As ARM states
> Currently, enabling synchronous calls to external scripts is not supported.
Sync run script is not supported.
With the addition of sync process spawn functionality in issue 3025, this is now doable.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3273Upgrade schema on startup2024-03-14T14:36:20ZAndrei Pavelandrei@isc.orgUpgrade schema on startupKea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.Kea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3272Refactor ProcessSpawn2024-03-14T14:34:16ZAndrei Pavelandrei@isc.orgRefactor ProcessSpawnThere are a few things that could be improved in the ProcessSpawn implementation. They become more apparent now that the synchronous functionality has been added to it, but the issues were present before too.
- The asynchronous implemen...There are a few things that could be improved in the ProcessSpawn implementation. They become more apparent now that the synchronous functionality has been added to it, but the issues were present before too.
- The asynchronous implementation of ProcessSpawn relies on having a global IO signal set and on having the IO service being periodically polled in order to wait for child processes which is why it uses the main IO service. For this reason:
- There needs to be a dedicated AsyncProcessSpawn class that should be a singleton to signal to the developer that it has global dependency objects.
- There needs to be a method in AsyncProcessSpawn that sets the IO service. It needs to be callable only once and called as close as possible to the creation of the main IO service. Spawning would throw if the IO service is not initialized. This is to avoid the current behavior which sets the IO service on the first ProcessSpawn creation which could be on a null IOServicePtr. See `src/hooks/dhcp/run_script/run_script.cc` or `src/hooks/dhcp/forensic_log/rotating_file.cc`.
- There should be a new class encapsulating the synchronous implementation, say `SyncProcessSpawn`. It does not have to be a singleton since waiting for the child process is done in the scope it was declared, and the object can be safely deleted afterwards.
- It is worth considering to change the sync variant to use an IO signal set and an IO service like the async variant, but these should not be global, but declarable by the developer, or even better, hidden by the implementation.
- The dismiss feature in spawn is not used in code. I suggest removing it.
- The async process spawn is currently fire-and-forget. It would be nice for the async process spawn to have the ability to be notified that the process has finished and that its status is available. Maybe with the help of a condition variable?backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4609ADB memory growth in 9.192024-02-28T06:53:58ZOndřej SurýADB memory growth in 9.19During the 25h test, it was discovered that ADB and main memory contextx grows suspiciously:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19](/uploads/5e5f039e83e4a892554001b6c7348e92/bindstats....During the 25h test, it was discovered that ADB and main memory contextx grows suspiciously:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19](/uploads/5e5f039e83e4a892554001b6c7348e92/bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19.png)
![bindstats.memory.contexts.main._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-main-9.19](/uploads/bad7883a65948bfd2946b84fe6505cdf/bindstats.memory.contexts.main._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-main-9.19.png)
The growth is much slower in 9.18:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1](/uploads/4cc202485a129130ecd978cf23ad452a/bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1.png)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4608Ensure static stub NS records are not returned2024-03-14T04:33:38ZMark AndrewsEnsure static stub NS records are not returnedstatic-stub synthesises NS record which shouldn't be returned to clients. Normally the NS records from the actual zone will be returned but not always.
- Setup a static-stub for "com" and disable minimal responses.
- query for foo.com ...static-stub synthesises NS record which shouldn't be returned to clients. Normally the NS records from the actual zone will be returned but not always.
- Setup a static-stub for "com" and disable minimal responses.
- query for foo.com NS (TTL is 600)
- wait 120 seconds
- query for foo.com A (TTL is 600)
- wait 500 seconds
- query for foo.com A
```
; <<>> DiG 9.19.20-dev <<>> foo.com -p 5555
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18858
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: dddb220761d487fa0100000065dec10ee6a221e99d9baa11 (good)
;; QUESTION SECTION:
;foo.com. IN A
;; ANSWER SECTION:
foo.com. 100 IN A 34.206.39.153
;; AUTHORITY SECTION:
com. 86400 IN NS com.
;; Query time: 2 msec
;; SERVER: ::1#5555(::1) (UDP)
;; WHEN: Wed Feb 28 16:13:50 AEDT 2024
;; MSG SIZE rcvd: 94
```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/3271Bump up version in configure.ac2024-02-28T15:40:24ZAndrei Pavelandrei@isc.orgBump up version in configure.acBump up version in configure.ac.Bump up version in configure.ac.kea2.5.7Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4607chain system test: mem.c:1311: INSIST(unreachable) failed2024-03-18T08:53:51ZMichal Nowakchain system test: mem.c:1311: INSIST(unreachable) failedJob [#4071483](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4071483) failed for f42a441b05408f4e816ea44a4780667a00c5fb86.
ns1 of the `chain` system test ended up in a bad place.
```
context: 0x7b3000001b00 (zonemgr-mctxpoo): 2 refe...Job [#4071483](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4071483) failed for f42a441b05408f4e816ea44a4780667a00c5fb86.
ns1 of the `chain` system test ended up in a bad place.
```
context: 0x7b3000001b00 (zonemgr-mctxpoo): 2 references
Dump of all outstanding memory allocations:
ptr 0x7b5000020200 size 496 file rbtdb.c line 3866
ptr 0x7b6000001000 size 1016 file rbt-zonedb.c line 2091
mem.c:1311: INSIST(unreachable) failed
```
```
2024-02-27 17:50:11 INFO:chain D:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D chain_tmp_qm1vyy5o-ns1 -m r'.
2024-02-27 17:50:11 INFO:chain D:Program terminated with signal SIGABRT, Aborted.
2024-02-27 17:50:11 INFO:chain D:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
2024-02-27 17:50:11 INFO:chain D:Downloading source file /usr/src/debug/glibc-2.38-16.fc39.x86_64/nptl/pthread_kill.c...
2024-02-27 17:50:11 INFO:chain D:44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
2024-02-27 17:50:11 INFO:chain D:[Current thread is 1 (Thread 0x7f96faa8a380 (LWP 77097))]
2024-02-27 17:50:11 INFO:chain D:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
2024-02-27 17:50:11 INFO:chain D:#1 0x00007f96fb0ed8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
2024-02-27 17:50:11 INFO:chain D:#2 0x00007f96fb09b8ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
2024-02-27 17:50:11 INFO:chain D:#3 0x00007f96fb0838ff in __GI_abort () at abort.c:79
2024-02-27 17:50:11 INFO:chain D:#4 0x00007f96fc0bee3c in __interceptor_abort (fake=-89613312) at ../../../../libsanitizer/tsan/tsan_interceptors_posix.cpp:1875
2024-02-27 17:50:11 INFO:chain D:#5 0x0000000000427e49 in assertion_failed (file=<optimized out>, line=1311, type=<optimized out>, cond=0x7f96fc065ac3 "unreachable") at main.c:234
2024-02-27 17:50:11 INFO:chain D:#6 0x00007f96fc00b194 in isc_assertion_failed (file=file@entry=0x7f96fc0624cb "mem.c", line=line@entry=1311, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f96fc065ac3 "unreachable") at assertions.c:48
2024-02-27 17:50:11 INFO:chain D:#7 0x00007f96fc02f45f in isc__mem_checkdestroyed () at mem.c:1311
2024-02-27 17:50:11 INFO:chain D:#8 0x00007f96fc02f54c in mem_shutdown () at mem.c:442
2024-02-27 17:50:11 INFO:chain D:#9 0x00007f96fc0da084 in __interceptor_pthread_once (o=o@entry=0x7f96fc07dec8 <shut_once>, f=f@entry=0x7f96fc02f533 <mem_shutdown>) at ../../../../libsanitizer/tsan/tsan_interceptors_posix.cpp:1551
2024-02-27 17:50:11 INFO:chain D:#10 0x00007f96fc02ce7e in isc__mem_shutdown () at mem.c:455
2024-02-27 17:50:11 INFO:chain D:#11 0x00007f96fc023088 in isc__shutdown () at lib.c:67
2024-02-27 17:50:11 INFO:chain D:#12 0x00007f96fd0ec0f2 in _dl_call_fini (closure_map=closure_map@entry=0x7f96fd0e98d0) at dl-call_fini.c:43
2024-02-27 17:50:11 INFO:chain D:#13 0x00007f96fd0f006e in _dl_fini () at dl-fini.c:114
2024-02-27 17:50:11 INFO:chain D:#14 0x00007f96fb09dfd6 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:111
2024-02-27 17:50:11 INFO:chain D:#15 0x00007f96fb09e11e in __GI_exit (status=<optimized out>) at exit.c:141
2024-02-27 17:50:11 INFO:chain D:#16 0x00007f96fb085151 in __libc_start_call_main (main=main@entry=0x429913 <main>, argc=argc@entry=12, argv=argv@entry=0x7ffe1fcbda88) at ../sysdeps/nptl/libc_start_call_main.h:74
2024-02-27 17:50:11 INFO:chain D:#17 0x00007f96fb08520b in __libc_start_main_impl (main=0x429913 <main>, argc=12, argv=0x7ffe1fcbda88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe1fcbda78) at ../csu/libc-start.c:360
2024-02-27 17:50:11 INFO:chain D:#18 0x0000000000418d35 in _start ()
```
[core.77097-backtrace.txt](/uploads/dfe2e0c9ee3a48df96c87773f2674a12/core.77097-backtrace.txt)
[core.77097.gz](/uploads/6a868166ed706bec348e2930ddc5fa5c/core.77097.gz)
[named.run](/uploads/ef60bc0ac117defd99c6f3c831f99368/named.run)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4606"dry-run" mode to help with dnssec-policy migration2024-02-28T10:46:36ZCarsten Strotmann"dry-run" mode to help with dnssec-policy migration### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC...### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC is good, there is currently no way to "verify" the new "dnssec-policy" configuration before enabling it. Experience has shown (in DNS training classes, but also in real world deployments) that there are many things that can go wrong:
- differences in the DNSSEC key configuration (old vs. new)
- file system permissions on the old key material
- file system location of the old key material
- issues with the time-events stored in the old key material
Going online with a slightly wrong configuration can cause an immediate key rollover, which might break the zone. Recovering from this situation is possible, but requires good knowledge of BIND 9 DNSSEC workings
### Request
Provide a "dnssec-policy dry-run" mode, where BIND 9 will log the next steps in the automatic DNSSEC management to the log files (e.g. category "DNSSEC"), but will not execute any changes to the DNSSEC signed zone or the key material. This will enable the user to test drive the new "dnssec-policy" to see if it will act as expected.
Admins can create a configuration with "dry-run" mode enabled, check the logfiles, and if the actions in the log-file match the expectations, the "dry-run" mode can be removed and the new configuration will become active.
### Links / referencesMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3270Perfmon UT MonitoredDuration.addSampleAndClear fails on MacOS2024-03-05T12:09:30ZThomas MarkwalderPerfmon UT MonitoredDuration.addSampleAndClear fails on MacOSAs @fdupont cited during 2.5.6 sanity checks, the UT fails on MacOS, see comment:
https://gitlab.isc.org/isc-projects/kea/-/issues/3265#note_440479
The test is too timing sensitive.As @fdupont cited during 2.5.6 sanity checks, the UT fails on MacOS, see comment:
https://gitlab.isc.org/isc-projects/kea/-/issues/3265#note_440479
The test is too timing sensitive.kea2.5.7Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3269Possible problem with RADIUS and shared networks2024-03-25T14:08:01ZFrancis DupontPossible problem with RADIUS and shared networksRADIUS uses the (re)selected subnet to fetch a cached host entry: this is not correct with shared networks where it should try all subnets of the shared networks without a guard incompatible with the query. And when RADIUS creates a new ...RADIUS uses the (re)selected subnet to fetch a cached host entry: this is not correct with shared networks where it should try all subnets of the shared networks without a guard incompatible with the query. And when RADIUS creates a new host entry for a reserved address it uses the (re)selected subnet instead of a subnet where the address belongs.
These two problems can make RADIUS to fail to find a cached entry: not a bug as the server will return the informations but not without performance impact...next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3268selectSubnet() should return a ConstSubnetXPtr2024-03-18T09:34:02ZFrancis DupontselectSubnet() should return a ConstSubnetXPtrTwo proposals to improve subnets:
- use for getSubnet the same code as for getBySubnetId (so O(log(N)) vs current O(N))
- selectSubnet should return a ConstSubnetXPtr i.e. `boost::shared_ptr<const SubnetX>`
The first proposal is trivi...Two proposals to improve subnets:
- use for getSubnet the same code as for getBySubnetId (so O(log(N)) vs current O(N))
- selectSubnet should return a ConstSubnetXPtr i.e. `boost::shared_ptr<const SubnetX>`
The first proposal is trivial tp implement so should be done ASAP if there is no good reason to keep the current full scan.
The second proposal is more complex: if a SubnetXPtr can be cast to a ConstSubnetXPtr it is not true for boost::any_cast (so for hook parameters) and of course it requires to not use a not const method (but as there is no reason to modify the subnet returned by selectSubnet one can consider that all not modifying methods should be const methods...).next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3267some option headers are missing in libkea dhcp include HEADERS2024-03-21T16:16:53ZPiotrek Zadrogasome option headers are missing in libkea dhcp include HEADERSSome options' headers are missing in `libkea_dhcp___include_HEADERS` in `src/lib/dhcp/Makefile.am`.
This results in those header missing in `isc-kea-dev` packages or under `include/kea/dhcp` path when kea built and installed from tarbal...Some options' headers are missing in `libkea_dhcp___include_HEADERS` in `src/lib/dhcp/Makefile.am`.
This results in those header missing in `isc-kea-dev` packages or under `include/kea/dhcp` path when kea built and installed from tarballs/sources.
Maybe this could be checked as part of release process?kea2.5.7Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/bind9/-/issues/4605re-enable enginepkcs11 system test2024-03-21T16:36:27ZTom Krizekre-enable enginepkcs11 system testThe `enginepkcs11` test was accidentally disabled by a wrong `prereq.sh` condition in https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5924/diffs?commit_id=2e9fd6d0c11d0648589da5779baeefb5b98e855e#8b557d8387b0ad5e06dad7a7c2c6f6...The `enginepkcs11` test was accidentally disabled by a wrong `prereq.sh` condition in https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5924/diffs?commit_id=2e9fd6d0c11d0648589da5779baeefb5b98e855e#8b557d8387b0ad5e06dad7a7c2c6f6521febff5e_16_16.
Once [enabled](https://gitlab.isc.org/isc-projects/bind9/-/commit/f3d402d1aa2e359caa741ce2b4742795a4a37224), the test has a couple of [failures](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4068956) that need to be addressed:
```
2024-02-26 17:25:39 INFO:enginepkcs11.test_enginepkcs11 I:Test SOA is signed for ecdsap256sha256.same-policy.views in view1 (65)
2024-02-26 17:25:42 INFO:enginepkcs11.test_enginepkcs11 I:failed (SOA RRset not signed)
2024-02-26 17:25:42 INFO:enginepkcs11.test_enginepkcs11 I:Test DNSKEY is signed for ecdsap256sha256.same-policy.views in view1 (66)
2024-02-26 17:25:45 INFO:enginepkcs11.test_enginepkcs11 I:failed (DNSKEY RRset not signed)
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4604Fix initial tests in masterfile system test2024-03-08T11:12:54ZMark AndrewsFix initial tests in masterfile system testAll three of the initial tests should have a known good output to test against.
The BIND 8 tests should be testing against ttl1.
There should be independent failure reporting for the first three tests.All three of the initial tests should have a known good output to test against.
The BIND 8 tests should be testing against ttl1.
There should be independent failure reporting for the first three tests.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)