27 Čec
2026
27 Čec
'26
21:30
Not sure how to capture better data (both platforms are running DEBUG level logs), but
I'm running into an odd issue.
DHCP server is Kea v3.0.3 (part of the OpnSense distribution, so can't be easily
updated to "latest") on FreeBSD.
DNS server is Knot v3.5.6 on Debian Trixie.
Kea is handing out both IPv4 and IPv6 addresses with:
"ddns-replace-client-name": "always"
set for all ranges /zones.
However, DDNS is not updating the zone records; A, AAAA, or PTR.
On the Kea side I get:
ERROR [kea-dhcp-ddns.d2-to-dns.0x90effa75010] DHCP_DDNS_ADD_FAILED DHCP_DDNS Request ID
00020129B7C04BF0FCBC35ACB85DE1ADD2747633BB2B32C6D7B4F195CF4667783622B5: Transaction
outcome Status: Failed, Event: UPDATE_FAILED_EVT, Forward change: failed, Reverse
change: failed, request: Type: 0 (CHG_ADD)
On the Knot DNS side I get:
ACL, allowed, action update, remote 192.168.144.1@57483 UDP
DDNS, processing 1 updates
DDNS, incoming, remote 192.168.144.1@57483 TCP, prerequisites not met (UPDATE prerequisite
not met)
DDNS, finished, no changes to the zone were made
But no clue as to what prerequisite is missing, unmet, incorrect, etc.
Any idea how I can dig up that nugget of information? Or increase verbosity to give me
enough DEBUG logs to figure it out?
27 Čec
27 Čec
21:49
On Mon, 2026-07-27 at 19:30 +0000, edv--- via knot-dns-users wrote:
But no clue as to what prerequisite is missing, unmet,
incorrect,
etc.
Any idea how I can dig up that nugget of information? Or increase
verbosity to give me enough DEBUG logs to figure it out?
Maybe it's failing one of the semantic checks?
https://www.knot-dns.cz/docs/latest/html/reference.html#semantic-checks
Just a thought.
--Billiam
28 Čec
28 Čec
16:56
Good thought - I did run the `kzonecheck` utility on all forward and reverse zones, with
no errors found in any.
I am not using DNSSEC internally, so ZONEMD should not be relevant.
# kzonecheck -v /srv/knot/zones/master/144.168.192.in-addr.arpa
debug: detected zone origin 144.168.192.in-addr.arpa.
No error found
# kzonecheck -vz /srv/knot/zones/master/lan.null-route.us
debug: detected zone origin lan.null-route.us.
No error found
--
Ed V.
8:53
Hi,
This log message usually appears when the DHCID record in the update prerequisite section
doesn't match the zone contents.
I'm not an expert on DHCP, so I can't explain why this happens.
We will try to add some debug logging for such cases.
Daniel
On 7/27/26 21:30, edv--- via knot-dns-users wrote:
Not sure how to capture better data (both platforms
are running DEBUG level logs), but I'm running into an odd issue.
DHCP server is Kea v3.0.3 (part of the OpnSense distribution, so can't be easily
updated to "latest") on FreeBSD.
DNS server is Knot v3.5.6 on Debian Trixie.
Kea is handing out both IPv4 and IPv6 addresses with:
"ddns-replace-client-name": "always"
set for all ranges /zones.
However, DDNS is not updating the zone records; A, AAAA, or PTR.
On the Kea side I get:
ERROR [kea-dhcp-ddns.d2-to-dns.0x90effa75010] DHCP_DDNS_ADD_FAILED DHCP_DDNS Request ID
00020129B7C04BF0FCBC35ACB85DE1ADD2747633BB2B32C6D7B4F195CF4667783622B5: Transaction
outcome Status: Failed, Event: UPDATE_FAILED_EVT, Forward change: failed, Reverse
change: failed, request: Type: 0 (CHG_ADD)
On the Knot DNS side I get:
ACL, allowed, action update, remote 192.168.144.1@57483 UDP
DDNS, processing 1 updates
DDNS, incoming, remote 192.168.144.1@57483 TCP, prerequisites not met (UPDATE
prerequisite not met)
DDNS, finished, no changes to the zone were made
But no clue as to what prerequisite is missing, unmet, incorrect, etc.
Any idea how I can dig up that nugget of information? Or increase verbosity to give me
enough DEBUG logs to figure it out?
--
16:59
Interesting. I recently had to rebuild several zone files as my ISP "refreshed"
my static IP range for both IPv4 and IPv6.
Is there a way to force acceptance and update despite DHCID not matching or not existing?
--
Ed V.
22:05
I think it's more of a question about Kea. Perhaps ddns-use-conflict-resolution ?
Daniel
On 7/28/26 16:59, edv--- via knot-dns-users wrote:
Interesting. I recently had to rebuild several zone
files as my ISP "refreshed" my static IP range for both IPv4 and IPv6.
Is there a way to force acceptance and update despite DHCID not matching or not existing?
--
Ed V.
--
17:50
Hi,
thank you for reaching us.
Just some explanation: one feature of DDNS updates is, that the client
(sending the update) may specify a prerequisites under which the update
shall be applied. They are part of the DDNS update request, and if they
do not hold, the request must be rejected by the server. See RFC 2136
§2.4. Unfortunately, Knot DNS does not (yet) log detailed information
about which prerequisites were requested and which exactly failed to be met.
Could you perhaps capture the communication with tcpdump (or similar)
and explore it with Wireshark (for example) to see which prerequisites
Kea requested, and check against the zone to see how they were not met?
Libor
On 27. 07. 26 21:30, edv--- via knot-dns-users wrote:
Not sure how to capture better data (both platforms
are running DEBUG level logs), but I'm running into an odd issue.
DHCP server is Kea v3.0.3 (part of the OpnSense distribution, so can't be easily
updated to "latest") on FreeBSD.
DNS server is Knot v3.5.6 on Debian Trixie.
Kea is handing out both IPv4 and IPv6 addresses with:
"ddns-replace-client-name": "always"
set for all ranges /zones.
However, DDNS is not updating the zone records; A, AAAA, or PTR.
On the Kea side I get:
ERROR [kea-dhcp-ddns.d2-to-dns.0x90effa75010] DHCP_DDNS_ADD_FAILED DHCP_DDNS Request ID
00020129B7C04BF0FCBC35ACB85DE1ADD2747633BB2B32C6D7B4F195CF4667783622B5: Transaction
outcome Status: Failed, Event: UPDATE_FAILED_EVT, Forward change: failed, Reverse
change: failed, request: Type: 0 (CHG_ADD)
On the Knot DNS side I get:
ACL, allowed, action update, remote 192.168.144.1@57483 UDP
DDNS, processing 1 updates
DDNS, incoming, remote 192.168.144.1@57483 TCP, prerequisites not met (UPDATE
prerequisite not met)
DDNS, finished, no changes to the zone were made
But no clue as to what prerequisite is missing, unmet, incorrect, etc.
Any idea how I can dig up that nugget of information? Or increase verbosity to give me
enough DEBUG logs to figure it out?
--
5
days inactive
6
days old
6 comments
4 participants
participants (4)
-
Billiam Crashkopf -
Daniel Salzman -
edv＠null-route.com -
Libor Peltan