DNS 18 BADTIME vs 22 BADTRUNC
Both DNS 18 (BADTIME) and 22 (BADTRUNC) belong to the DNS Response Codes (RCODEs) category. 18 indicates that signature out of time window. The TSIG signature timestamp is outside the allowed clock skew, indicating a time synchronization issue. Meanwhile, 22 means that bad truncation. The TSIG record was truncated in a way that makes it impossible to verify the message signature.
Description
Signature out of time window. The TSIG signature timestamp is outside the allowed clock skew, indicating a time synchronization issue.
When You See It
The clocks on the DNS client and server are too far apart (usually more than 5 minutes), causing TSIG signature validation to fail.
How to Fix
Synchronize clocks on both machines using NTP. Check that the TSIG fudge value (allowed skew) is reasonable — the default 300 seconds is usually sufficient.
Description
Bad truncation. The TSIG record was truncated in a way that makes it impossible to verify the message signature.
When You See It
A large DNS response was truncated (TC bit set) but the TSIG MAC was computed over the full message, making the truncated version unverifiable.
How to Fix
Retry the query over TCP to avoid truncation. If using UDP, ensure your EDNS buffer size is large enough to receive the full signed response.
Key Differences
DNS 18: Signature out of time window. The TSIG signature timestamp is outside the allowed clock skew, indicating a time synchronization issue.
DNS 22: Bad truncation. The TSIG record was truncated in a way that makes it impossible to verify the message signature.
You encounter 18 when the clocks on the DNS client and server are too far apart (usually more than 5 minutes), causing TSIG signature validation to fail.
You encounter 22 when a large DNS response was truncated (TC bit set) but the TSIG MAC was computed over the full message, making the truncated version unverifiable.
When to Use Which
For 18 (BADTIME): Synchronize clocks on both machines using NTP. Check that the TSIG fudge value (allowed skew) is reasonable — the default 300 seconds is usually sufficient. For 22 (BADTRUNC): Retry the query over TCP to avoid truncation. If using UDP, ensure your EDNS buffer size is large enough to receive the full signed response.