Question

Difficulty: HardTroubleshooting DNS and Name Resolution Services

A network administrator is investigating a name resolution issue on a server attempting to query an internal DNS zone for DNSSEC-signed records. When executing `dig @10.10.1.5 api.partner.corp +dnssec`, the command returns the following output:

text
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48219
;; flags: qr rd ra tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;api.partner.corp. IN A

;; Query time: 12 msec
;; SERVER: 10.10.1.5#53(10.10.1.5)

Subsequent attempts by applications to resolve `api.partner.corp` time out or fail. Which of the following is the most likely root cause of this failure?

  1. An intermediate network security rule is blocking TCP port 53 traffic, preventing the client from retrying the truncated query over TCP.Answer
  2. B
    The DNS server at 10.10.1.5 returned an authoritative empty answer because no A record exists for api.partner.corp.
  3. C
    Standard DNS queries are misconfigured on the client to use TCP port 53 instead of the required UDP port 53 for initial requests.
  4. D
    The local system HOSTS file contains an invalid IPv6 AAAA mapping that overrides the server response.

Answer

An intermediate network security rule is blocking TCP port 53 traffic, preventing the client from retrying the truncated query over TCP.
The `dig` output highlights the `tc` (truncated) flag in the header. When DNSSEC signatures or large resource record sets cause a DNS response to exceed the standard UDP buffer size (512 bytes), the DNS server truncates the response and sets the `tc` bit. Standard DNS clients upon seeing `tc` automatically re-query the DNS server using TCP port 53. If a firewall or security group permits UDP 53 but blocks TCP 53, the client's secondary query fails, preventing name resolution.

Step-by-Step Solution

1
Analyze the header flags in the `dig` command output.
The `flags: qr rd ra tc` line contains the `tc` (Truncated) flag, indicating the server truncated the response because it exceeded the maximum allowed UDP packet payload size (512 bytes without extended EDNS0 buffering).
Identifying DNS truncation is essential to understanding why full record payloads (such as large DNSSEC responses) cannot be transmitted over UDP.
2
Determine the standard client behavior following a DNS truncated response.
When a client receives a response with the `tc` flag set, RFC standard behavior dictates that the client must re-issue the DNS query over TCP port 53.
TCP provides stream-based transmission capable of handling larger payloads beyond the UDP MTU limit.
3
Diagnose why subsequent application resolution attempts time out.
If TCP port 53 is blocked by a network access control list (ACL) or firewall between the client and server, the TCP fallback fails, causing resolution timeouts.
Both UDP port 53 and TCP port 53 must be open across firewalls to support large DNS responses and DNSSEC.

Key Concept

DNS Truncation (TC Flag) and TCP Port 53 Fallback
Rate this question