Examkin

Question

Difficulty: Very hardTroubleshooting DNS and Name Resolution Services

A network engineer is troubleshooting name resolution issues on a client workstation attempting to resolve a large DNSSEC-signed resource record hosted on an internal DNS server (192.168.10.5). The engineer runs `dig` and receives the following output:

text
$ dig @192.168.10.5 api.internal.corp +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41052
;; flags: qr aa tc rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Truncation occurred.
;; COMMUNICATIONS ERROR: cannot reach server over TCP (192.168.10.5:53)

Which of the following represents the most likely root cause of this failure?

  1. An intermediate firewall rule is dropping TCP port 53 traffic between the client workstation and the DNS server, preventing query retry after UDP truncation.Answer
  2. B
    The DNS server is misconfigured to require TCP transport for initial query processing rather than standard UDP transport.
  3. C
    The authoritative DNS server lacks a valid CNAME record mapping for the requested hostname, causing an empty truncated answer block.
  4. D
    The utility output indicates the DNS server is operating in non-recursive mode, requiring the workstation to query root hint servers directly.

Answer

An intermediate firewall rule dropping TCP port 53 traffic between the client workstation and the DNS server, preventing query fallback after UDP payload truncation.
DNS relies on UDP port 53 for fast, low-overhead name resolution. However, when response data (such as large DNSSEC records) exceeds UDP length limits, the server truncates the response and sets the TC (Truncation) flag in the DNS header. By RFC standard, the client resolver must immediately retry the query over TCP port 53. The error message `cannot reach server over TCP` explicitly indicates that while initial UDP queries reach the server, network security filters (firewall/ACL) are blocking TCP port 53 traffic required for the fallback query.

Step-by-Step Solution

1
Analyze the DNS header flags in the `dig` command output.
The `tc` (Truncated) flag is set in the header (`flags: qr aa tc rd ra`), indicating that the complete DNS payload exceeds the maximum allowable UDP packet size (typically 512 bytes without EDNS0 or exceeding negotiated EDNS limits).
When a DNS response is too large to fit in a single UDP datagram, the server truncates the response and sets the TC flag to notify the client.
2
Evaluate the client resolver behavior following UDP truncation.
Standard DNS protocol behavior dictates that upon receiving a response with the TC flag set, the resolver MUST re-issue the query using TCP on port 53.
TCP provides stream-based delivery that accommodates large response payloads (such as DNSSEC keys/signatures or extensive record sets).
3
Interpret the specific communications error in the output.
`COMMUNICATIONS ERROR: cannot reach server over TCP (192.168.10.5:53)` demonstrates that UDP port 53 communication succeeded, but TCP port 53 transport failed.
This distinct differential failure (UDP working, TCP failing) points directly to a firewall/ACL rule blocking TCP port 53 while permitting UDP port 53.

Key Concept

DNS Transport Protocols and TCP Fallback upon Response Truncation (TC Flag)
Rate this question

Topics

Troubleshooting DNS and Name Resolution Services

More questions from this topic