GSS-TSIG Broken response
GSS-TSIG Broken response
MS DNS servers seem to return a broken DDNS response, copying the entire original request (including the TSIG RR) just setting the QR bit. The only exception seems to be a response for a successful DDNS request using TSIG, in which case the TSIG RR of the response has a valid MAC for the response. In our experience the broken responses can be sent when a DDNS prerequisite check fails, authentication fails, or non-secure DDNS is allowed.
In the case of GSS-TSIG, the copied (broken) GSS token triggers the following error:
INFO [kea-dhcp-ddns.gss-tsig-hooks/4678.139690935890624] GSS_TSIG_VERIFY_FAILED GSS-TSIG verify failed: gss_verify_mic failed with GSSAPI error: Major = 'A token had an invalid Message Integrity Check (MIC)' (393216), Minor = 'Packet was replayed in wrong direction' (100002).
it's not surprising since it's the token sent by Kea and the direction is indeed wrong. I also suspect it's irrelevant to configuring or not configuring a reverse mapping zone.
We might provide a way to disable integrity check on the response (usually DDNS response is not that important) to work around this buggy behavior of MS server. But that's probably considered to be too radical. (Relatively) fortunately, these cases are usually just treated as an update failure anyway, so probably we'll just need to live with the bug.