SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
DNS New Added 26 September 2026

dig: ;; Truncated, retrying in TCP mode

The answer did not fit in the UDP message size the client offered, so the server set the TC bit and the client started again over TCP. The retry normally succeeds, so the visible symptom is a slow lookup, or an intermittent failure wherever a firewall permits port 53 over UDP but not TCP.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Reproduce, then measure: how large is the answer and does TCP work
dig example.com TXT +bufsize=1232
dig example.com TXT +tcp

# A big DNSSEC or SPF answer is the usual cause, not a broken server
dig example.com TXT +dnssec | grep 'MSG SIZE'

# Port 53 over TCP is not optional for DNS, open it both ways
sudo nft list ruleset | grep -w 53
nc -vz 10.0.0.53 53

# A path MTU black hole breaks large UDP answers before the TC bit helps
ping -M do -s 1400 10.0.0.53

# A sensible EDNS buffer avoids fragmentation without forcing every query to TCP
# BIND: edns-udp-size 1232; max-udp-size 1232;
grep -E 'edns-udp-size|max-udp-size' /etc/bind/named.conf.options

How to diagnose DNS errors

DNS errors are best diagnosed by working down the delegation chain: root, TLD, authoritative nameserver, then the record itself. The most common mistake is testing only through your local resolver, which caches both good and bad answers and hides where the failure actually is. NXDOMAIN means the name definitively does not exist; SERVFAIL means the resolver could not get a valid answer, which is usually a DNSSEC or authoritative-server problem, not a typo.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Query the authoritative nameserver directly, bypassing all caches: dig @ns1.example.com example.com A. If that answers correctly, you have a caching or propagation issue, not a records issue.
  2. Trace the full delegation with dig +trace example.com. This shows exactly which level of the hierarchy stops returning answers.
  3. Distinguish NXDOMAIN from SERVFAIL from timeout. They have three entirely different causes. Check the status: line in dig output.
  4. For SERVFAIL, test with DNSSEC validation disabled: dig +cd example.com. If that succeeds, the problem is a broken DNSSEC chain, often after a key rollover.
  5. Check TTLs before declaring propagation broken. A record with a 24-hour TTL genuinely will not update for resolvers that cached it, and there is no way to force them.

Tools worth reaching for

  • dig +trace
  • dig @authoritative-ns
  • dig +cd (DNSSEC bypass)
  • kdig
  • resolvectl status

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

datatracker.ietf.org bind9.readthedocs.io

Related DNS errors

See all 20 DNS errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.