← DNS: understand and diagnose resolution
05 / 5 · 18 MIN

DNS transport and DNSSEC validation

Separate truncation, TCP access, and authenticity failures.

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.

IN PRACTICE

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

Take this idea with you

Transport, DNS integrity, and application security are different controls.

Create account

Reference: RFC 7766: DNS over TCP · DNS RFC 1034/1035 with RFC 2181, 2308, 3596, 4033, 7766 and 8767; dig BIND 9.20