Introduction

DNS usually starts over UDP, but not every answer fits cleanly into a small datagram. Large responses, DNSSEC data, and oversized record sets can trigger truncation, forcing resolvers to retry over TCP. Problems arise when that fallback path is blocked or the zone consistently generates larger answers than the network path handles well. The fix is to determine whether the issue is simply large answers or broken fallback and EDNS behavior.

Symptoms

  • DNS tools show the TC truncation flag on responses
  • Some clients resolve correctly while others fail or time out
  • Large TXT, DNSSEC-signed, or multi-record answers are more likely to break
  • Public resolvers behave differently depending on network path or resolver implementation
  • The issue started after enabling DNSSEC or adding more records to the zone

Common Causes

  • DNS responses exceed practical UDP size limits for the path or client
  • EDNS is misconfigured, unsupported, or stripped by middleboxes
  • TCP fallback to the authoritative server is blocked or unreliable
  • DNSSEC signatures increase answer size beyond what the path handles cleanly
  • The zone returns overly large responses because of record sprawl or unnecessary data

Step-by-Step Fix

  1. Query the affected record types and confirm whether the answer is being truncated over UDP.
  2. Check whether TCP queries to the same authoritative servers succeed, since truncation alone is not fatal if TCP fallback works.
  3. Review EDNS support and advertised buffer behavior on the authoritative server and along the network path.
  4. Inspect whether firewalls or filtering devices block or mishandle DNS over TCP.
  5. Consider response size drivers such as DNSSEC signatures, oversized TXT records, or large record sets returned together.
  6. Reduce unnecessary response bulk where possible or adjust DNS design so clients do not depend on oversized answers.
  7. Re-test from multiple public resolvers and networks after correcting TCP reachability or oversized response causes.
  8. Confirm the affected record now resolves reliably without client-specific breakage.
  9. Monitor large-answer zones carefully whenever DNSSEC or email-auth records expand, because response size issues often grow gradually.