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?
- An intermediate network security rule is blocking TCP port 53 traffic, preventing the client from retrying the truncated query over TCP.Cevap
- BThe DNS server at 10.10.1.5 returned an authoritative empty answer because no A record exists for api.partner.corp.
- CStandard DNS queries are misconfigured on the client to use TCP port 53 instead of the required UDP port 53 for initial requests.
- DThe local system HOSTS file contains an invalid IPv6 AAAA mapping that overrides the server response.
Cevap
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.
Adım Adım Çözüm
Anahtar Kavram
DNS Truncation (TC Flag) and TCP Port 53 Fallback