DNS 9 NOTAUTH vs 22 BADTRUNC
Both DNS 9 (NOTAUTH) and 22 (BADTRUNC) belong to the DNS Response Codes (RCODEs) category. 9 indicates that server Not Authoritative for zone, or Not Authorized. The server is not authoritative for the zone named in the Zone section. Meanwhile, 22 means that bad truncation. The TSIG record was truncated in a way that makes it impossible to verify the message signature.
설명
Server Not Authoritative for zone, or Not Authorized. The server is not authoritative for the zone named in the Zone section.
이 코드를 보게 되는 경우
You sent a dynamic update or zone operation to a server that is not the authoritative master for that zone, or the server rejected it due to TSIG authentication failure.
해결 방법
Send the update to the correct primary authoritative server for the zone. If using TSIG, verify the key name and secret match on both client and server.
설명
Bad truncation. The TSIG record was truncated in a way that makes it impossible to verify the message signature.
이 코드를 보게 되는 경우
A large DNS response was truncated (TC bit set) but the TSIG MAC was computed over the full message, making the truncated version unverifiable.
해결 방법
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.
주요 차이점
DNS 9: Server Not Authoritative for zone, or Not Authorized. The server is not authoritative for the zone named in the Zone section.
DNS 22: Bad truncation. The TSIG record was truncated in a way that makes it impossible to verify the message signature.
You encounter 9 when you sent a dynamic update or zone operation to a server that is not the authoritative master for that zone, or the server rejected it due to TSIG authentication failure.
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.
언제 어떤 것을 사용할지
For 9 (NOTAUTH): Send the update to the correct primary authoritative server for the zone. If using TSIG, verify the key name and secret match on both client and server. 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.