Concept and mechanism
DNS does not operate exclusively over UDP. TCP is part of required support for implementations covered by current rules, and a truncated response may require another query over TCP. A network allowing only UDP may appear functional for small answers and fail in other cases. Diagnosis must observe transport and client behavior without concluding that timeout proves incorrect zone data.
Guided application
DNSSEC adds mechanisms for DNS data-origin authentication, integrity, and authenticated denial of existence. It does not automatically encrypt query contents or validate the application using the address. Validation failure may prevent one resolver accepting an answer that a nonvalidating resolver accepts. If a key or delegation change coincides with SERVFAIL, investigate the trust chain and signatures with the responsible team. Permanently disabling validation hides the problem and removes the intended control.
Small answers work, but a larger answer is truncated and its TCP attempt fails. Investigate DNS TCP connectivity and network policy before changing the application address.
Common pitfalls
Blocking TCP because DNS is assumed UDP-only; confusing DNSSEC with confidentiality; disabling validation without diagnosis.
Related topics: Resolver, authority, and client context · Records, aliases, and query type
Transport, DNS integrity, and application security are different controls.
Reference: RFC 7766: DNS over TCP · DNS RFC 1034/1035 with RFC 2181, 2308, 3596, 4033, 7766 and 8767; dig BIND 9.20