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? --
--
