A network administrator is troubleshooting name resolution issues on a Linux workstation. The system successfully resolves typical small domain requests, but queries expecting large responses fail.
The administrator executes the following diagnostic commands from the workstation:
text dig TXT large-record.enterprise.internal ;; Truncated, retrying in TCP mode. ;; communications error to 10.20.4.53#53: timed out dig +notcp TXT large-record.enterprise.internal ;; ;; WARNING: recursion requested but not available ;; GOT ANSWER: ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: Messages truncated; TC bit is set.
Which of the following are the MOST likely causes of this name resolution failure? (Select TWO.)
- An intermediate firewall or network Access Control List (ACL) is dropping traffic on TCP port 53.Answer
- The requested DNS response payload exceeds the maximum UDP packet buffer size, forcing a fallback to TCP.Answer
- CThe local recursive resolver lacks an authoritative canonical name (CNAME) record pointing to an AAAA record.
- DThe DNS client software is misconfigured to use mDNS multicast port 5353 for primary name resolution.
Answer
The primary causes are that the DNS response payload exceeds the UDP packet buffer limit (setting the TC bit) and an intermediate firewall or network ACL is blocking the required fallback connection over TCP port 53.
DNS relies on UDP port 53 for standard lightweight lookups. When a DNS response (such as a large TXT record set) exceeds the maximum allowed UDP payload size, the server returns a response with the Truncated (TC) header flag set. This signals the client to retry the request over TCP port 53. In this scenario, the UDP query succeeds and receives the TC flag, but the subsequent TCP connection times out because a firewall or network access control list is blocking TCP port 53.
Step-by-Step Solution
Key Concept
DNS Protocol Transport Modes (UDP vs TCP Port 53) and Truncation (TC Bit) Behavior