ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-28T20:25:49Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3297Perfmon-Hook-Task-5 Add Event Stack Processing2024-03-28T20:25:49ZThomas MarkwalderPerfmon-Hook-Task-5 Add Event Stack ProcessingComplete Hook Task 5: Add Event Stack Processing - Process event stacks into MonitoredDuration updates, implement report timer, and alarm processing
See https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#perfm...Complete Hook Task 5: Add Event Stack Processing - Process event stacks into MonitoredDuration updates, implement report timer, and alarm processing
See https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#perfmon-hook-taskskea2.5.8Thomas MarkwalderThomas Markwalderhttps://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/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/stork/-/issues/1320Duplicated rows in the service table2024-02-28T16:28:53ZSlawek FigielDuplicated rows in the service tableThe problem was reported [on the Stork-users mailing list](https://lists.isc.org/pipermail/stork-users/2024-February/000245.html).
The `service` table rows may be duplicated on some unknown conditions. It causes the HA status displayed ...The problem was reported [on the Stork-users mailing list](https://lists.isc.org/pipermail/stork-users/2024-February/000245.html).
The `service` table rows may be duplicated on some unknown conditions. It causes the HA status displayed on the Dashboard to diverge from the status presented on the application page.
The user reports that the problem occurs in Stork 1.15 but was also observed in the previous versions. The first installed version was 1.12.
Stork was installed long after configuring HA in Kea.
It seems the same problem was reported in #616 and #818.
We should check if the problem were fixed correctly in 1.7 and if the invalid table state may preserved from the previous versions.
We should also analyze if adding the unique constraint on the `service` table would be beneficial to avoid similar issues.1.16Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4598statschannel test may fail due to a missing response2024-02-22T09:53:52ZTom Krizekstatschannel test may fail due to a missing response`statschannel` system tests [`test_traffic_xml`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4054038) ([9.18 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4002144)) or [`test_traffic_json`](https://gitlab.isc.org/isc-project...`statschannel` system tests [`test_traffic_xml`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4054038) ([9.18 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4002144)) or [`test_traffic_json`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999177) may fail with:
```
_______________________________ test_traffic_xml _______________________________
[gw2] linux -- Python 3.12.1 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_xml.py:134: in test_traffic_xml
generic.test_traffic(fetch_traffic_xml, statsip="10.53.0.2", statsport=statsport)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:211: in test_traffic
check_traffic(data, exp)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:185: in check_traffic
assert ordered_data == ordered_expected
E AssertionError: assert [('dns-tcp-re...v6', []), ...] == [('dns-tcp-re...v6', []), ...]
E At index 6 diff: ('dns-udp-responses-sizes-sent-ipv4', [('96-111', 1)]) != ('dns-udp-responses-sizes-sent-ipv4', [('816-831', 1), ('96-111', 1)])
E Full diff:
E [
E ('dns-tcp-requests-sizes-received-ipv4', [('16-31', 1)]),
E ('dns-tcp-requests-sizes-received-ipv6', []),
E ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1)]),
E ('dns-tcp-responses-sizes-sent-ipv6', []),
E ('dns-udp-requests-sizes-received-ipv4', [('32-47', 2)]),
E ('dns-udp-requests-sizes-received-ipv6', []),
E - ('dns-udp-responses-sizes-sent-ipv4', [('816-831', 1), ('96-111', 1)]),
E ? ----------------
E + ('dns-udp-responses-sizes-sent-ipv4', [('96-111', 1)]),
E ('dns-udp-responses-sizes-sent-ipv6', []),
E ]
```
```
______________________________ test_traffic_json _______________________________
[gw3] linux -- Python 3.11.2 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_json.py:104: in test_traffic_json
generic.test_traffic(fetch_traffic_json, statsip="10.53.0.2", statsport=statsport)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:229: in test_traffic
check_traffic(data, exp)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:185: in check_traffic
assert ordered_data == ordered_expected
E AssertionError: assert [('dns-tcp-re...v6', []), ...] == [('dns-tcp-re...v6', []), ...]
E At index 2 diff: ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1), ('96-111', 1)]) != ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1), ('816-831', 1), ('96-111', 1)])
E Full diff:
E [
E ('dns-tcp-requests-sizes-received-ipv4',
E [('16-31',
E 1),
E ('32-47',
E 2)]),
E ('dns-tcp-requests-sizes-received-ipv6',
E []),
E ('dns-tcp-responses-sizes-sent-ipv4',
E [('64-79',
E - 1),
E - ('816-831',
E 1),
E ('96-111',
E 1)]),
E ('dns-tcp-responses-sizes-sent-ipv6',
E []),
E ('dns-udp-requests-sizes-received-ipv4',
E [('32-47',
E 2)]),
E ('dns-udp-requests-sizes-received-ipv6',
E []),
E ('dns-udp-responses-sizes-sent-ipv4',
E [('816-831',
E 1),
E ('96-111',
E 1)]),
E ('dns-udp-responses-sizes-sent-ipv6',
E []),
E ]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4586Don't count expired / future RRSIGs in verification failure quota2024-02-24T08:17:15ZMark AndrewsDon't count expired / future RRSIGs in verification failure quotaExpired / future RRSIGs don't trigger a public key verification.Expired / future RRSIGs don't trigger a public key verification.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/kea/-/issues/3247changes in hammer for rocky linux2024-03-28T08:11:54ZMarcin Godzinachanges in hammer for rocky linuxWe need to extend Hammer to build on Rocky Linux 9. We have a business need for this.We need to extend Hammer to build on Rocky Linux 9. We have a business need for this.kea2.5.8Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/stork/-/issues/1305Help tip is exceed the viewport2024-03-28T15:29:13ZSlawek FigielHelp tip is exceed the viewportThe issue was found by @piotrek during 1.15 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1296#note_434131
Minor UI issue - sometimes help tool-tip Header/title is out of view (it happened when I started to resize my...The issue was found by @piotrek during 1.15 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1296#note_434131
Minor UI issue - sometimes help tool-tip Header/title is out of view (it happened when I started to resize my browser window)
![image](https://gitlab.isc.org/isc-projects/stork/uploads/f3d815e3344748445a4f4ff5164801fc/image.png)1.16Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/bind9/-/issues/4554Signature expiration calculation backwards compatibility bug2024-02-24T07:53:48ZMatthijs Mekkingmatthijs@isc.orgSignature expiration calculation backwards compatibility bugThe `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `sig...The `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `signatures-validity - signatures-refresh`) which is wrong: it should be using a range of 0 to `signatures-refresh`.
The `sig-validity-interval` that was used for `auto-dnssec` defined two parameters, the first being the signatures validity (same as `dnssec-policy`'s `signatures-validity`), the optional second one being the minimum bound of the signatures validity. It also serves as a signatures refresh. Basically the refresh value is the difference between the first and second parameter.
So the second parameter actually has two meanings: It serves as a jitter and a refresh value.
With `dnssec-policy` there is not yet a way to define `jitter`. The `signatures-refresh` is actually defined as the.
Two things need to be done:
- [x] Add a configuration option to `dnssec-policy` to set desired jitter.
- [x] Ensure resign interval is used correctly.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4550Resolve license aggregation for "reuse lint"2024-02-07T16:19:55ZMichal NowakResolve license aggregation for "reuse lint"`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: Pen...`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: PendingDeprecationWarning: Copyright and licensing
information for 'COPYRIGHT' has been found in both 'COPYRIGHT' and in the DEP5 file located at '.reuse/dep5'.
The information for these two sources has been aggregated. In the future this behaviour will change, and you will
need to explicitly enable aggregation. See <https://github.com/fsfe/reuse-tool/issues/779>. You need do nothing
yet. Run with `--suppress-deprecation` to hide this warning.
...
```Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4517dnssec-verify reports errors in NSEC3 chain2024-02-24T07:53:57ZLibor Peltandnssec-verify reports errors in NSEC3 chain### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the f...### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Bad NSEC3 record for fadb1aa3f.6DA7ffbF, bit map mismatch
Expected and found NSEC3 chains not equal
Break in NSEC3 chain at: VKGD3TE5QRGB6S0KJH6UV3FKS9FUMRIV
Expected: 01EAMK8ES71TN6TKHOK512LQMCORC5O9
Found: 0R6S95GSLHH7HT7MFN2N1NJGNFS7Q2CQ
DNSSEC completeness test failed (failure).
```
I'd say that the NSEC3 chain is however correct.
Some notes:
- opt-out is not used
- `fadb1aa3f.6da7ffbf.` -> `01eamk8es71tn6tkhok512lqmcorc5o9.6da7ffbf.` (first NSEC3 lexicographically, but this probably doesnt care)
- `427e09.owa.6da7ffbf.` -> `vkgd3te5qrgb6s0kjh6uv3fks9fumriv.6da7ffbf.` (last NSEC3 lexicographically)
- node `fadb1aa3f.6da7ffbf.` is "weird" in the way that it's a delegation with non-authoritative data: MX and even DNSKEY(!), but this shouldn't influence the chaining of NSEC3, moreover, it relates to the bitmap at 01EAMK... and not VKGD3T...
### BIND version affected
```
$ dnssec-verify -V
dnssec-verify 9.18.18-0ubuntu0.22.04.1-Ubuntu
```
### Steps to reproduce
Use faketime as the RRSIGs are expired already. It doesn't matter since the errors are related to NSEC3s and not signatures.
The zone file in question is attached.
Just call `$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone`
### What is the current *bug* behavior?
Verify reports errors in the attached zone's NSEC3 chain.
### What is the expected *correct* behavior?
No errors reported.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/stork/-/issues/1265Hosts reservations filter improvements2024-03-28T16:02:26ZPiotrek ZadrogaHosts reservations filter improvementsText Input type filter used currently in Hosts reservations view has some limitations and drawbacks (https://gitlab.isc.org/isc-projects/stork/-/issues/917#note_423973).
E.g. it is not possible to filter out all reservations in 2 subnet...Text Input type filter used currently in Hosts reservations view has some limitations and drawbacks (https://gitlab.isc.org/isc-projects/stork/-/issues/917#note_423973).
E.g. it is not possible to filter out all reservations in 2 subnets.
This could be improved by leaving existing Text Input only for filtering `byText` and introducing something different for filtering by `appId`, `subnetId`, `keaSubnetId`, `global`. This could be e.g. `multiselect` (https://primeng.org/multiselect).1.16Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/bind9/-/issues/4485Update httppicoparser2023-12-13T16:43:09ZOndřej SurýUpdate httppicoparserThis sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78This sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4475Data races in isc_buffer_peekuint8, rdataset_settrust, and memmove2024-02-24T07:54:00ZMichal NowakData races in isc_buffer_peekuint8, rdataset_settrust, and memmoveJob [#3848477](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848477) failed for c4fcdbefc5ac65e62f8d16ba78737aa6174c9592.
There are three new types of TSAN errors in the failed `respdiff-long:tsan` CI job.
I did not happen [yesterd...Job [#3848477](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848477) failed for c4fcdbefc5ac65e62f8d16ba78737aa6174c9592.
There are three new types of TSAN errors in the failed `respdiff-long:tsan` CI job.
I did not happen [yesterday](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3843810) on 64ef6968f379fa220c2a2d76311705b4e248e286, so should this be caused by a new code, the only theoretically relevant MR is !8515.
```
WARNING: ThreadSanitizer: data race
Read of size 1 at 0x000000000001 by main thread:
#0 isc_buffer_peekuint8 ../../lib/isc/include/isc/buffer.h:847
#1 isc_buffer_getuint8 ../../lib/isc/include/isc/buffer.h:854
#2 dns_ncache_getsigrdataset lib/dns/ncache.c:630
#3 validate_ncache lib/dns/validator.c:2388
#4 validate_nx lib/dns/validator.c:2431
#5 validator_start lib/dns/validator.c:2994
#6 isc__async_cb lib/isc/async.c:111
#7 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#8 thread_body lib/isc/thread.c:85
#9 isc_thread_main lib/isc/thread.c:116
#10 isc_loopmgr_run lib/isc/loop.c:454
#11 main bin/named/main.c:1574
Previous write of size 1 at 0x000000000001 by thread T0001:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:202
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 thread_run lib/isc/thread.c:100
Location is heap block of size 1015 at 0x000000000020 allocated by main thread:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647
#1 mallocx lib/isc/jemalloc_shim.h:67
#2 mem_get lib/isc/mem.c:303
#3 isc__mem_get lib/isc/mem.c:675
#4 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:332
#5 dns__rbtdb_addrdataset lib/dns/rbtdb.c:3153
#6 dns__db_addrdataset lib/dns/db.c:681
#7 addoptout lib/dns/ncache.c:283
#8 dns_ncache_add lib/dns/ncache.c:103
#9 ncache_adderesult lib/dns/resolver.c:6358
#10 validated lib/dns/resolver.c:5385
#11 validator_done_cb lib/dns/validator.c:210
#12 isc__async_cb lib/isc/async.c:111
#13 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#14 thread_body lib/isc/thread.c:85
#15 isc_thread_main lib/isc/thread.c:116
#16 isc_loopmgr_run lib/isc/loop.c:454
#17 main bin/named/main.c:1574
Thread T0001 'isc-loop-0002' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
SUMMARY: ThreadSanitizer: data race ../../lib/isc/include/isc/buffer.h:847 in isc_buffer_peekuint8
```
```
WARNING: ThreadSanitizer: data race
Write of size 1 at 0x000000000001 by main thread:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:202
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 isc_thread_main lib/isc/thread.c:116
#9 isc_loopmgr_run lib/isc/loop.c:454
#10 main bin/named/main.c:1574
Previous write of size 1 at 0x000000000001 by thread T0001:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:202
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 thread_run lib/isc/thread.c:100
Location is heap block of size 1015 at 0x000000000014 allocated by thread T0002:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647
#1 mallocx lib/isc/jemalloc_shim.h:67
#2 mem_get lib/isc/mem.c:303
#3 isc__mem_get lib/isc/mem.c:675
#4 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:332
#5 dns__rbtdb_addrdataset lib/dns/rbtdb.c:3153
#6 dns__db_addrdataset lib/dns/db.c:681
#7 addoptout lib/dns/ncache.c:283
#8 dns_ncache_add lib/dns/ncache.c:103
#9 ncache_adderesult lib/dns/resolver.c:6358
#10 validated lib/dns/resolver.c:5385
#11 validator_done_cb lib/dns/validator.c:210
#12 isc__async_cb lib/isc/async.c:111
#13 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#14 thread_body lib/isc/thread.c:85
#15 thread_run lib/isc/thread.c:100
Thread T0001 'isc-loop-0001' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
Thread T0002 'isc-loop-0002' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
SUMMARY: ThreadSanitizer: data race lib/dns/ncache.c:499 in rdataset_settrust
```
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by main thread:
#0 memmove ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810
#1 memmove ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:808
#2 memmove /usr/include/x86_64-linux-gnu/bits/string_fortified.h:36
#3 dns_name_fromregion lib/dns/name.c:739
#4 dns_ncache_current lib/dns/ncache.c:701
#5 validate_ncache lib/dns/validator.c:2382
#6 validate_nx lib/dns/validator.c:2431
#7 validator_start lib/dns/validator.c:2994
#8 isc__async_cb lib/isc/async.c:111
#9 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#10 thread_body lib/isc/thread.c:85
#11 isc_thread_main lib/isc/thread.c:116
#12 isc_loopmgr_run lib/isc/loop.c:454
#13 main bin/named/main.c:1574
Previous write of size 1 at 0x000000000014 by thread T0001:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:200
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 thread_run lib/isc/thread.c:100
Location is heap block of size 1047 at 0x000000000021 allocated by thread T0001:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647
#1 mallocx lib/isc/jemalloc_shim.h:67
#2 mem_get lib/isc/mem.c:303
#3 isc__mem_get lib/isc/mem.c:675
#4 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:332
#5 dns__rbtdb_addrdataset lib/dns/rbtdb.c:3153
#6 dns__db_addrdataset lib/dns/db.c:681
#7 addoptout lib/dns/ncache.c:283
#8 dns_ncache_add lib/dns/ncache.c:103
#9 ncache_adderesult lib/dns/resolver.c:6358
#10 validated lib/dns/resolver.c:5385
#11 validator_done_cb lib/dns/validator.c:210
#12 isc__async_cb lib/isc/async.c:111
#13 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#14 thread_body lib/isc/thread.c:85
#15 thread_run lib/isc/thread.c:100
Thread T0001 'isc-loop-0001' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
SUMMARY: ThreadSanitizer: data race /usr/include/x86_64-linux-gnu/bits/string_fortified.h:36 in memmove
```
I restarted the job, and this is a [reproducible issue](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3849392).May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4458dnssec auto fails across multiple views + unable to add/remove DS records fro...2023-12-04T05:39:28ZTom Shawdnssec auto fails across multiple views + unable to add/remove DS records from second view + invalid DS records### Summary
- When using multiple views, the affected views fail to manage dnssec properly
- When using dnssec to auto sign zones, across multiple views, all but one of the views will fail to add DS records through nsupdate.
- The view ...### Summary
- When using multiple views, the affected views fail to manage dnssec properly
- When using dnssec to auto sign zones, across multiple views, all but one of the views will fail to add DS records through nsupdate.
- The view fails to manage and purge old key/state/private files and these start to build up over time
- Unable to get DS records, publish CDS log entries stop appearing for the view
### BIND version used
BIND 9.18.20-1+ubuntu22.04.1+deb.sury.org+1-Ubuntu
### Steps to reproduce
Create a config which has two views, with the same domain in each view. One of the views must only be available to an internal ip range (internal), the other must be available from all (external). Enable dnssec on both domains in both views using separate policies.
### What is the current *bug* behavior?
- keys in the internal view will not be managed correctly and will build up over time
- nsupdate will appear to add/delete the DS records correctly but these are not added or deleted in bind.
### What is the expected *correct* behavior?
- keys in both views should be managed correctly
- nsupdate should be able to manipulate the DS records in the internal view
### Relevant configuration files
I will share my configs privately if possible
Use this yearly internal policy for TDL level domains
```
dnssec-policy "yearly-internal" {
keys {
ksk lifetime P365D algorithm ECDSAP384SHA384;
zsk lifetime P1D algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT5M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT10M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT10M;
signatures-validity-dnskey PT10M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
Use this aggressive standard internal policy for sub domains
dnssec-policy "standard" {
keys {
ksk lifetime PT40M algorithm ECDSAP384SHA384;
zsk lifetime PT20M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl 60;
publish-safety PT2M;
retire-safety PT2M;
purge-keys PT10M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT10M;
signatures-validity-dnskey PT10M;
//
max-zone-ttl 300;
parent-ds-ttl 60;
parent-propagation-delay 60;
nsec3param iterations 10 optout no salt-length 16;
};
options {
check-names master ignore;
check-names slave ignore;
check-names response ignore;
masterfile-format text;
listen-on-v6 { none; };
listen-on port 53 { 127.0.0.1; 165.227.238.11; 10.0.254.1; 10.0.254.2; };
directory "/var/cache/bind";
auth-nxdomain no; # conform to RFC1035
querylog yes;
pid-file "/var/run/named/named.pid";
include "/etc/bind/named.options.transfer.conf";
# if running a natted server, set the public ip address here
# this will not work in a multihomed box (specifically linode fails)
# notify the NS servers - only on master
notify yes;
# some dnssec stuff
include "/etc/bind/named.options.dnssec.conf";
max-cache-size 10485760;
};
```
Zone file
```
#ns1.node.flipkick.media
zone "entitywind.dev" {
key-directory "/var/cache/bind/keys/internals-master";
file "internals.master.dev.entitywind.db";
update-policy {
grant 127.0.0.1 subdomain entitywind.dev;
grant internal subdomain entitywind.dev;
grant internal zonesub any;
grant internal-externaldns subdomain entitywind.dev;
grant internal-externaldns zonesub any;
grant internal-rndc-key subdomain entitywind.dev;
grant internal-rndc-key zonesub any;
};
include "/etc/bind/named.zone.internals-master.conf";
include "/etc/bind/named.zone.dnssec.policy.yearly-internal.conf";
parental-agents { "externals"; };
};
#ns1.node.flipkick.media
zone "node.entitywind.dev" {
key-directory "/var/cache/bind/keys/internals-master";
file "internals.master.dev.entitywind.db";
update-policy {
grant 127.0.0.1 subdomain entitywind.dev;
grant internal subdomain entitywind.dev;
grant internal zonesub any;
grant internal-externaldns subdomain entitywind.dev;
grant internal-externaldns zonesub any;
grant internal-rndc-key subdomain entitywind.dev;
grant internal-rndc-key zonesub any;
};
include "/etc/bind/named.zone.internals-master.conf";
include "/etc/bind/named.zone.dnssec.policy.yearly-internal.conf";
parental-agents { "externals"; };
};
```
### Relevant logs and/or screenshots
```
28-Nov-2023 12:58:02.305 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/25339 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/53449 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/43625 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/26195 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/33520 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/26171 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/37281 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/7041 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/63692 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/9156 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/29571 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/44364 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/44662 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/40817 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/22890 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/64449 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/39830 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/30931 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/57355 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/23733 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/25059 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/20634 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/2754 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/19617 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/61960 (KSK) is now inactive
```
### Possible fixes
Run two bind servers and attach to differing ipshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4453Switching to a different dnssec-policy broke my zone.2024-02-24T07:54:16ZBjörn PerssonSwitching to a different dnssec-policy broke my zone.### Summary
My zone was previously signed with a KSK and a ZSK with unlimited lifetime. I switched the zone over to a dnssec-policy using CSKs and automatic key rotation. After the DS record was updated, most of the RRSIG records were r...### Summary
My zone was previously signed with a KSK and a ZSK with unlimited lifetime. I switched the zone over to a dnssec-policy using CSKs and automatic key rotation. After the DS record was updated, most of the RRSIG records were removed, leaving the zone broken to validating resolvers.
### BIND version used
```
# named -V
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.19=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
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/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
I have two zones that both exist in an external and an internal view. Each zone was previously signed with a KSK and a ZSK with unlimited lifetime. To proceed cautiously with the change to `dnssec-policy` I defined one policy that matched the existing keys and another that would use CSKs and automatic key rotation:
```
dnssec-policy "as_it_was" {
keys {
ksk lifetime unlimited algorithm rsasha256 2048;
zsk lifetime unlimited algorithm rsasha256 2048;
};
dnskey-ttl P1D;
purge-keys 0;
};
dnssec-policy "automation" {
keys {
csk lifetime P1M algorithm rsasha256 2048;
};
dnskey-ttl P1D;
max-zone-ttl P1D;
signatures-validity P1W;
signatures-refresh P2D;
};
```
First I switched the zones from "`auto-dnssec maintain;`" to "`dnssec-policy as_it_was;`". Bind continued using the existing keys. Once I had the exchange of CDS and DS records working between my zones and the parent zone, I switched one zone over to "`dnssec-policy automation;`" in both views.
The rollover from the old keys to a CSK seemed to go smoothly, but after a while I discovered that the zone was only partially signed in the external view. Several records lacked RRSIG records. Dynamic updates of the unsigned records caused corresponding RRSIG records to appear.
After that initial problem, the following rollover from one CSK to another worked fine, so I proceeded to switch the second zone over to "`dnssec-policy automation;`". This time I took notes and watched for missing signatures.
2023-11-18 16:05:49 a CSK was generated. DNSKEY, CDS and CDNSKEY were signed with both the old KSK and the CSK. SOA got a new signature by the old ZSK. All other records kept their existing signatures.
2023-11-19 17:10:49 CDS and CDNSKEY records for the CSK were published. DNSKEY, CDS and CDNSKEY got new signatures by the KSK and the CSK. SOA was signed with the ZSK and the CSK.
2023-11-20 17:10:49 Bind noticed that DS had been updated in the parent zone.
2023-11-20 18:15:49 the ZSK and all its signatures were removed. DNSKEY, CDS and CDNSKEY got new signatures by the CSK and the KSK. SOA got a new signature by the CSK. All other records were left without RRSIG records.
This time I fixed the external view with "`rndc sign xn--rombobjrn-67a.se IN external`". All the unsigned records were then signed with the CSK. DNSKEY, CDS, CDNSKEY and SOA had their signatures renewed. I left the internal view alone.
2023-11-21 19:10:50 the KSK was removed. DNSKEY, CDS, CDNSKEY and SOA got new signatures by the CSK. At the same time, many but not all other records in the internal view were finally signed with the CSK, having lacked signatures for 24 hours and 55 minutes. Some more records were signed a few minutes later.
As I'm posting this, one NS and one MX record in the internal view are still unsigned after more than four days.
### What is the current *bug* behavior?
The zone becomes only partially signed. Validating resolvers reject the unsigned records.
### What is the expected *correct* behavior?
All records should be signed with the new key before the old keys and signatures are removed.
### Relevant configuration files
See the policies above. After the changes, all the zone declarations look essentially like this:
```
zone "xn--rombobjrn-67a.se" {
type master;
file "/var/lib/bind/db.xn--rombobjrn-67a.se.external";
dnssec-policy automation;
parental-agents { ::1; };
inline-signing no;
update-policy { [omitted] };
};
```
### Relevant logs and/or screenshots
Excerpts from the system log:
```
2023-11-19T17:10:49.436468+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-19T17:10:49.437286+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-19T17:10:49.488666+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-19T17:10:49.489192+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-19T17:10:49.501444+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-19T17:10:49.502076+01:00 cutie named[443161]: CDS (SHA-256) for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.502515+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.502904+01:00 cutie named[443161]: CDS for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.503279+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.530343+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-19T17:10:49.530897+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-19T17:10:49.534298+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-19T17:10:49.534962+01:00 cutie named[443161]: CDS (SHA-256) for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.535337+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.535684+01:00 cutie named[443161]: CDS for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.536038+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.637732+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 19-Nov-2023 18:10:49.432
2023-11-19T17:10:49.638433+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092737)
2023-11-19T17:10:49.651717+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 19-Nov-2023 18:10:49.432
2023-11-19T17:10:49.673263+01:00 cutie named[443161]: client @0x7efdf9b21368 10.1.0.5#54619 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092736 -> 2023092737)
2023-11-19T17:10:49.674244+01:00 cutie named[443161]: client @0x7efdf9b21368 10.1.0.5#54619 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 23 records, 5465 bytes, 0.004 secs (1366250 bytes/sec) (serial 2023092737)
2023-11-19T17:10:50.192637+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.2.1#57043 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092736 -> 2023092737)
2023-11-19T17:10:50.193661+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.2.1#57043 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 23 records, 5465 bytes, 0.001 secs (5465000 bytes/sec) (serial 2023092737)
```
```
2023-11-20T17:10:49.472806+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-20T17:10:49.473891+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-20T17:10:49.525113+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:49.525655+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:49.529210+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:49.530341+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 20-Nov-2023 18:10:49.466
2023-11-20T17:10:49.557565+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:49.558183+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:49.561418+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:49.562620+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 20-Nov-2023 18:10:49.466
2023-11-20T17:10:49.617384+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/17339 seen published at Mon Nov 20 17:10:49 2023
2023-11-20T17:10:49.621343+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/53584 seen withdrawn at Mon Nov 20 17:10:49 2023
2023-11-20T17:10:49.624985+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-20T17:10:49.667546+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:49.668097+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:49.671602+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:49.672714+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 20-Nov-2023 18:15:49.618
2023-11-20T17:10:50.027333+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/17339 seen published at Mon Nov 20 17:10:50 2023
2023-11-20T17:10:50.031352+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/53584 seen withdrawn at Mon Nov 20 17:10:50 2023
2023-11-20T17:10:50.035151+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-20T17:10:50.077904+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:50.078540+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:50.081828+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:50.083015+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 20-Nov-2023 18:15:49.030
```
```
2023-11-20T18:15:49.036472+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-20T18:15:49.076389+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T18:15:49.077010+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T18:15:49.088905+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/13398/RSASHA256 from DNSKEY RRset.
2023-11-20T18:15:49.089406+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK) is now deleted
2023-11-20T18:15:49.089784+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T18:15:49.192756+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 20-Nov-2023 18:20:49.033
2023-11-20T18:15:49.193416+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092738)
2023-11-20T18:15:49.275467+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#41397 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092737 -> 2023092739)
2023-11-20T18:15:49.278365+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#41397 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 3 messages, 128 records, 38648 bytes, 0.004 secs (9662000 bytes/sec) (serial 2023092739)
2023-11-20T18:15:49.622949+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-20T18:15:49.664238+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T18:15:49.664712+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T18:15:49.667624+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/13398/RSASHA256 from DNSKEY RRset.
2023-11-20T18:15:49.668019+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK) is now deleted
2023-11-20T18:15:49.668373+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T18:15:49.764336+01:00 cutie named[443161]: client @0x7efdebdc5168 10.1.2.1#58091 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092737 -> 2023092739)
2023-11-20T18:15:49.767341+01:00 cutie named[443161]: client @0x7efdebdc5168 10.1.2.1#58091 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 3 messages, 128 records, 38648 bytes, 0.004 secs (9662000 bytes/sec) (serial 2023092739)
2023-11-20T18:15:49.779256+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 20-Nov-2023 18:20:49.621
2023-11-20T18:15:54.192437+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092739)
```
```
2023-11-21T13:15:40.402451+01:00 cutie named[443161]: received control channel command 'sign xn--rombobjrn-67a.se IN external'
2023-11-21T13:15:40.405362+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T13:15:40.431241+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T13:15:40.431697+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T13:15:40.433742+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-21T13:15:40.528574+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:10:50.395
2023-11-21T13:15:40.529172+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092740)
2023-11-21T13:15:40.773096+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#33623 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092739 -> 2023092742)
2023-11-21T13:15:40.774513+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#33623 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 46 records, 12419 bytes, 0.004 secs (3104750 bytes/sec) (serial 2023092742)
2023-11-21T13:15:41.172719+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#33203 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092739 -> 2023092745)
2023-11-21T13:15:41.174657+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#33203 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 2 messages, 89 records, 24907 bytes, 0.004 secs (6226750 bytes/sec) (serial 2023092745)
2023-11-21T13:15:45.528370+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092750)
2023-11-21T13:15:45.561710+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#52787 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092742 -> 2023092750)
2023-11-21T13:15:45.564494+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#52787 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 2 messages, 114 records, 31108 bytes, 0.004 secs (7777000 bytes/sec) (serial 2023092750)
2023-11-21T13:15:46.078928+01:00 cutie named[443161]: client @0x7efdfa51bd68 10.1.2.1#60701 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092745 -> 2023092750)
2023-11-21T13:15:46.080874+01:00 cutie named[443161]: client @0x7efdfa51bd68 10.1.2.1#60701 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 2 messages, 71 records, 18769 bytes, 0.001 secs (18769000 bytes/sec) (serial 2023092750)
```
```
2023-11-21T19:10:50.400377+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:10:50.432532+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:10:50.433038+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:10:50.443664+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/53584/RSASHA256 from DNSKEY RRset.
2023-11-21T19:10:50.444123+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now deleted
2023-11-21T19:10:50.511795+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:15:50.396
2023-11-21T19:10:50.512265+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092751)
2023-11-21T19:10:50.576696+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#54307 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092750 -> 2023092752)
2023-11-21T19:10:50.577645+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#54307 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 27 records, 5832 bytes, 0.001 secs (5832000 bytes/sec) (serial 2023092752)
2023-11-21T19:10:50.626991+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:10:50.660686+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:10:50.661150+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:10:50.663077+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/53584/RSASHA256 from DNSKEY RRset.
2023-11-21T19:10:50.663489+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now deleted
2023-11-21T19:10:50.738310+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 19:15:50.624
2023-11-21T19:10:51.191122+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#43631 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092750 -> 2023092752)
2023-11-21T19:10:51.191859+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#43631 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 27 records, 5832 bytes, 0.001 secs (5832000 bytes/sec) (serial 2023092752)
2023-11-21T19:10:55.511787+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092752)
2023-11-21T19:15:50.404325+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:15:50.427941+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:15:50.428397+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:15:50.440377+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:20:49.398
2023-11-21T19:15:50.630905+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:15:50.656580+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:15:50.657098+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:15:50.659929+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 19:20:49.626
2023-11-21T19:20:49.405293+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:20:49.429191+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:49.429646+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:49.438021+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:20:50.399
2023-11-21T19:20:49.630959+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:20:49.656677+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:49.657172+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:49.659897+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 19:20:50.627
2023-11-21T19:20:50.401138+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:20:50.427552+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:50.428010+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:50.434902+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 20:20:50.399
2023-11-21T19:20:50.629148+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:20:50.654607+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:50.655054+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:50.657686+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 20:20:50.627
```
Some possibly useful status data from when the zone lacked signatures:
```
# rndc dnssec -status xn--rombobjrn-67a.se IN external
dnssec-policy: automatik
current time: Tue Nov 21 12:57:26 2023
key: 17339 (RSASHA256), CSK
published: yes - since Sat Nov 18 16:05:49 2023
key signing: yes - since Sat Nov 18 16:05:49 2023
zone signing: yes - since Sat Nov 18 16:05:49 2023
Next rollover scheduled on Mon Dec 18 15:00:49 2023
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- zone rrsig: omnipresent
- key rrsig: omnipresent
key: 13398 (RSASHA256), ZSK
published: no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: hidden
- zone rrsig: unretentive
key: 53584 (RSASHA256), KSK
published: yes - since Sun Nov 3 04:26:07 2019
key signing: yes - since Sun Nov 3 04:26:07 2019
Rollover is due since Sun Nov 19 18:05:49 2023
- goal: hidden
- dnskey: omnipresent
- ds: unretentive
- key rrsig: omnipresent
# rndc zonestatus xn--rombobjrn-67a.se IN external
name: xn--rombobjrn-67a.se
type: primary
files: /var/lib/bind/db.xn--rombobjrn-67a.se.external
serial: 2023092739
nodes: 42
last loaded: Tue, 24 Oct 2023 12:43:57 GMT
secure: no
key maintenance: automatic
next key event: Tue, 21 Nov 2023 18:10:50 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
```
The output of `rndc zonestatus` changed when I ran `rndc sign`:
```
# rndc zonestatus xn--rombobjrn-67a.se IN external
name: xn--rombobjrn-67a.se
type: primary
files: /var/lib/bind/db.xn--rombobjrn-67a.se.external
serial: 2023092750
nodes: 42
last loaded: Tue, 24 Oct 2023 12:43:57 GMT
secure: yes
inline signing: no
key maintenance: automatic
next key event: Tue, 21 Nov 2023 18:10:50 GMT
next resign node: 7c2ecd07f155648431e0f94b89247d713c5786e1e73e953f2fe7eca3._openpgpkey.xn--rombobjrn-67a.se/NSEC
next resign time: Wed, 22 Nov 2023 22:55:09 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4449too long CNAME chains do not elicit SERVFAIL or even log message2023-11-23T15:08:44ZPetr Špačekpspacek@isc.orgtoo long CNAME chains do not elicit SERVFAIL or even log message### Summary
CNAME chain length is currently limited to ~ 16 steps. Chains longer than this limit are cut short, but the RDCODE is still NOERROR. This creates impression that the final hop might be NODATA answer.
Also I can't see any lo...### Summary
CNAME chain length is currently limited to ~ 16 steps. Chains longer than this limit are cut short, but the RDCODE is still NOERROR. This creates impression that the final hop might be NODATA answer.
Also I can't see any log message in logs that resolution was terminated prematurely.
### BIND version used
* ~"Affects v9.19": a819d3644634997a78b162988156e90f409e1ce8
* ~"Affects v9.18": 6817bf1284fe8aea303365d2dd17bc5523e7a41b
* ~"Affects v9.16": 161d69aba357fa830bb6ef2b097b0447929041f0
* ~"Affects v9.11 (EoL)" : v9.11.37-S1
* Other versions were not tested
### Steps to reproduce
* Setup an auth zone with too long CNAME chain:
- [local.zone](/uploads/af4b4f699adb8b3bf87d5cac31b5d33f/local.zone)
- [named.conf](/uploads/2a0c44310bfbe99a2ffe6bbc1b36bacc/named.conf)
Query for it in default resolver config.
### What is the current *bug* behavior?
RCODE=NOERROR despite the incomplete CNAME chain.
```
$ dig c0000.local.testiscorg.ch. A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20544
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 102100bdc30994f717d0d76d655f5b7d3a1f039d04cd3a86 (good)
;; QUESTION SECTION:
;c0000.local.testiscorg.ch. IN A
;; ANSWER SECTION:
c0000.local.testiscorg.ch. 0 IN CNAME c0001.local.testiscorg.ch.
c0001.local.testiscorg.ch. 0 IN CNAME c0002.local.testiscorg.ch.
c0002.local.testiscorg.ch. 0 IN CNAME c0003.local.testiscorg.ch.
c0003.local.testiscorg.ch. 0 IN CNAME c0004.local.testiscorg.ch.
c0004.local.testiscorg.ch. 0 IN CNAME c0005.local.testiscorg.ch.
c0005.local.testiscorg.ch. 0 IN CNAME c0006.local.testiscorg.ch.
c0006.local.testiscorg.ch. 0 IN CNAME c0007.local.testiscorg.ch.
c0007.local.testiscorg.ch. 0 IN CNAME c0008.local.testiscorg.ch.
c0008.local.testiscorg.ch. 0 IN CNAME c0009.local.testiscorg.ch.
c0009.local.testiscorg.ch. 0 IN CNAME c0010.local.testiscorg.ch.
c0010.local.testiscorg.ch. 0 IN CNAME c0011.local.testiscorg.ch.
c0011.local.testiscorg.ch. 0 IN CNAME c0012.local.testiscorg.ch.
c0012.local.testiscorg.ch. 0 IN CNAME c0013.local.testiscorg.ch.
c0013.local.testiscorg.ch. 0 IN CNAME c0014.local.testiscorg.ch.
c0014.local.testiscorg.ch. 0 IN CNAME c0015.local.testiscorg.ch.
c0015.local.testiscorg.ch. 0 IN CNAME c0016.local.testiscorg.ch.
c0016.local.testiscorg.ch. 0 IN CNAME c0017.local.testiscorg.ch.
```
### What is the expected *correct* behavior?
Same output but SERVFAIL.
### Relevant logs and/or screenshots
There is no log message indicating that the chain was cut prematurely. Here's named log running at `-d 99` from the main branch: [named.log](/uploads/4e9e9f8c70bf4fbc187082914a4b06ac/named.log)
### Other implementations
- PowerDNS Recursor 4.9.1 SERVFAILs and cuts the chain on c0011
- Knot Resolver 5.7.0 SERVFAILs and cuts the chain on c0013
- Unbound 1.19.0 commit 197bf154 SERVFAILs and does not return anything in the ANSWER section. [PCAP](/uploads/abb00b0409388e4a5cedf867a934e9f7/dns.pcap) suggests it stops chasing after encountering c0011.https://gitlab.isc.org/isc-projects/bind9/-/issues/4423named starts up slow when many zones reference the same dnssec-policy2024-02-24T07:54:22ZMatthijs Mekkingmatthijs@isc.orgnamed starts up slow when many zones reference the same dnssec-policyWhile rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones af...While rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones after reload/reconfig and CPU usage of the named process remains at 100% and it takes quite a few minutes for named to start responding to queries after such a reload/reconfig request.
When spreading my zones to 10 identical policies, cpu usage goes well above 100% (using more threads I assume) and this is speeding
things up really nice.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3129extend hammer to prepare kea to test it with TSAN2024-03-28T08:12:03ZWlodzimierz Wencelextend hammer to prepare kea to test it with TSANWhile checking what is really needed to run fully automated system tests against KEA with TSAN enabled I came to a conclusion that different compilation procedure have to be incorporated in hammer.
In TSAN job in jenkins we are using:
`...While checking what is really needed to run fully automated system tests against KEA with TSAN enabled I came to a conclusion that different compilation procedure have to be incorporated in hammer.
In TSAN job in jenkins we are using:
```
CXX=clang++
CXXFLAGS="-g3 -ggdb -O0 -fsanitize=thread -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches"
TSAN_OPTIONS="detect_deadlocks=1 second_deadlock_stack=1"
```kea2.5.8Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/stork/-/issues/1193CA returns number overflow on ipv6 stats2024-03-22T12:56:27ZSlawek FigielCA returns number overflow on ipv6 statsThe issue was found during [1.13 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408666) by @slawek.
I have observed a weird error in logs:
```
stork-1130-agent-kea6-1 | INFO COMMAND_RECEIVED R...The issue was found during [1.13 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408666) by @slawek.
I have observed a weird error in logs:
```
stork-1130-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'statistic-get-all'
stork-1130-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command statistic-get-all received from remote address 127.0.0.1
stork-1130-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'statistic-get-all'
stork-1130-agent-kea6-1 | time="2023-10-10 12:40:51" level="error" msg="Failed to parse responses from Kea: response result from Kea != 0: 1, text: internal server error: unable to parse server's answer to the forwarded message: Number overflow: 36893488147419103232 in <wire>:0:8422" file=" promkeaexporter.go:850 "
stork-1130-agent-kea6-1 | time="2023-10-10 12:40:51" level="error" msg="Some errors were encountered while collecting stats from Kea: response result from Kea != 0: 1, text: internal server error: unable to parse server's answer to the forwarded message: Number overflow: 36893488147419103232 in <wire>:0:8422\nisc.org/stork/agent.(*GetAllStatisticsResponse).UnmarshalJSON\n\tisc.org/stork/agent/promkeaexporter.go:149\nencoding/json.(*decodeState).array\n\tencoding/json/decode.go:507\nencoding/json.(*decodeState).value\n\tencoding/json/decode.go:364\nencoding/json.(*decodeState).unmarshal\n\tencoding/json/decode.go:181\nencoding/json.Unmarshal\n\tencoding/json/decode.go:108\nisc.org/stork/agent.(*PromKeaExporter).collectStats\n\tisc.org/stork/agent/promkeaexporter.go:847\nisc.org/stork/agent.(*PromKeaExporter).statsCollectorLoop\n\tisc.org/stork/agent/promkeaexporter.go:710\nruntime.goexit\n\truntime/asm_amd64.s:1650" file=" promkeaexporter.go:712 "
```1.16Slawek FigielSlawek Figiel2024-05-29