When the Answer Does Not Fit
Truncation, TCP, and telling three kinds of failure apart
Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.
What you'll be able to do
- ▸Explain what the TC bit means and what a resolver does about it
- ▸Distinguish NXDOMAIN, NODATA, SERVFAIL and REFUSED
- ▸Say why negative answers are cached and what happens when they are not
Before this lesson — it builds directly on:
DNS was built around one small question and one small answer over UDP, with no connection setup. That decision is why name resolution costs a single round trip rather than four, and it is the right decision — but it came with a size limit, and answers grew.
Rather than redesign, DNS gained a bit: TC, truncated. It means "the answer exists and did not fit; ask again over TCP". One bit, and it is why DNS is one of the few protocols that genuinely uses both transports for the same operation.
Watch these fields in the lab: dns.truncated
- NXDOMAINglossary
- rcode 3. The name does not exist. An authoritative statement about the whole name, and cacheable.
- NODATA
- rcode 0 with an empty answer section. The name exists and has no records of the type asked for. Success, read as failure more often than any other response.
- SERVFAIL
- rcode 2. The server tried and could not answer — a broken delegation, an unreachable upstream, or a DNSSEC validation failure.
- REFUSED
- rcode 5. The server could answer and will not, for you. A policy decision rather than a fault.
✓ Concept check — before you open the packets
These test the idea, not the trace. You should be able to answer them from the explanation above.
Now that you understand the concept, observe how it appears in the packet exchange.
The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.