Summary

  • The DNS TC bit says that a reply exceeded the capacity of its transmission channel. RFC 2181 later made the semantic boundary precise: TC is for a required RRset that cannot be included in full, and a client should ignore the truncated response rather than treating its visible records as complete.
  • TCP carried the larger retry, but it did not remain an exceptional last resort. RFC 7766 made UDP and TCP support mandatory for general-purpose DNS and allowed a resolver to choose TCP first; RFC 9210 turned TCP capacity, filtering and monitoring into ordinary operating responsibilities.

The honest answer did not fit

The original DNS specification joined two unlike properties. UDP made ordinary questions cheap: no connection setup, little state, easy retransmission to another server. But RFC 1035 limited a UDP DNS message to 512 bytes, excluding the IP and UDP headers. A longer message had to be cut short.

That limit could have produced a dangerous ambiguity. If five records existed and only three fit, a consumer might read three as the authoritative set. A transport shortage would then masquerade as a fact about the namespace.

DNS reserved the TC bit for the opposite statement. The message had been truncated because it was longer than the channel permitted. TC did not say that a name was absent, that the visible records were preferable, or that the server had changed its view. It said the current container was insufficient.

The small bit therefore carried more than a size warning. It kept the authority to describe a name separate from the mechanics that delivered the description.

An RRset had to remain one unit of evidence

Ten years later, RFC 2181 removed an important ambiguity. Records with the same owner name, class and type form a resource record set, or RRset. When a query asks for that data, the set is the unit that matters.

TC should be set only when an RRset required by the response cannot be included in its entirety. Running out of space for merely useful additional information is different. The server may omit the whole extra RRset and send the response with TC clear; a client that needs the missing auxiliary data can ask for it separately.

When TC is set, the rule becomes stricter. The client should ignore that response and query again through a mechanism that permits a larger reply, such as TCP. A partial RRset may physically remain in the packet, but it has not earned the status of a usable answer.

This is the design's deepest choice. The receiver is not asked to guess which bytes were important or merge an attractive fragment with old cache state. Incompleteness invalidates the response for the question that required the missing set.

The server signalled a boundary; the resolver chose the next move

TC is a negative capability signal. The server reports what this transmission could not carry. It does not open a connection on the client's behalf or dictate every future transport.

In the familiar sequence, a resolver sends a UDP query, receives TC=1, then repeats the question over TCP to the same server or tries an appropriate alternative. TCP places a two-byte length field before each DNS message and can deliver a reply larger than one datagram. It also introduces connection state, admission decisions and timeout costs.

Those costs remain with the parties that incur them. A resolver decides whether to retry, reuse a connection or select another server. A server decides how many connections it can admit and how long an idle session may remain. Neither decision gives an intermediary permission to reinterpret the DNS data.

The architecture is efficient because the cheap path is allowed to declare its own limit. It is trustworthy because that declaration prevents the cheap path from laundering an incomplete result into truth.

EDNS enlarged the envelope, not the guarantee

RFC 6891 gave DNS an extension mechanism and let the requestor advertise the UDP payload size it could receive. The old 512-byte ceiling no longer described every exchange. Larger answers could often stay on UDP.

An advertised number, however, is not evidence that every link, tunnel, firewall or host along the path will carry a datagram of that size. IP fragmentation can be lost, filtered or abused. DNSSEC also added signatures and proof material, while IPv6 and new record uses increased the occasions on which answers grew.

EDNS and TC therefore perform different jobs. EDNS states an offered capacity. TC states that the response as composed did not fit the usable capacity. Raising a budget does not remove the need for an honest overflow signal or for another transport.

The distinction matters operationally. Treating the advertised buffer size as a path guarantee can produce timeouts with no TC response at all. Treating EDNS as a replacement for TCP leaves the resolver without a reliable way to recover a large answer when UDP delivery fails.

TCP ceased to be a ceremonial exception

For years, DNS over TCP was commonly described as the path for zone transfers and oversized retries. That vocabulary encouraged implementations and firewalls to treat it as unusual. The result was a brittle contract: the header could instruct a client to seek more capacity while the network blocked the capacity the protocol expected.

RFC 7766, published in 2016, put TCP on firmer ground. General-purpose authoritative servers, recursive servers, forwarders and stub resolvers must support both UDP and TCP. More subtly, the document relaxed the older rule that non-zone-transfer questions had to begin with UDP. A resolver may choose TCP first for local operational reasons and should reuse an already open connection.

TCP thus became a valid alternative, not merely a punishment for a reply that grew too large. That correction also prevents a historical mechanism from becoming a false universal claim: TC often triggers TCP, but modern DNS transport choice is broader than one fixed two-step ritual.

Making a reliable path scale required new discipline

A TCP handshake can add latency. Closing the connection after one answer pays that price repeatedly. RFC 7766 therefore recommends connection reuse and query pipelining: a client can send multiple questions without waiting for each previous response, while the server processes them concurrently.

The answers may return out of order. A client must match them to outstanding queries rather than assuming stream order equals question order. A server must not mistake one TCP segment for one complete DNS message; stream data must be assembled according to the DNS length framing.

Scale also depends on restraint. Clients should minimize concurrent connections to an individual server. Servers may set per-client or per-subnet limits. Idle sessions should close according to policy, and timeouts must recognize complete DNS messages rather than rewarding an attacker for dribbling fragments of a stream.

The reliable path is not free. The standard's answer was not to disable it, but to put resource authority beside interoperability duty.

Operations finally had to see both halves of DNS

RFC 9210 turned implementation support into an operating contract. Resolvers and servers must service both UDP and TCP; network operators must allow both in the general case. Filtering TCP DNS is harmful because it removes the recovery path for answers that do not survive UDP.

The requirement does not abolish limits. A server may bound resources, but it must not refuse a query merely because another transport might have sufficed. That is an important allocation of power: operators retain control over capacity without turning one transport into a second-class source of DNS truth.

Monitoring has to follow. A packet capture that understands only UDP will miss normal traffic and attacks. TCP-aware tooling must reassemble streams, track reused connections, understand pipelined questions and tolerate out-of-order responses. Otherwise the channel that protects completeness becomes an observability blind spot.

Fragmentation made the old bit newly valuable

The later Internet did not remove the pressure on UDP; it made the path more variable. RFC 9715 recommends avoiding IP fragmentation for DNS over UDP, bounding payloads by the smallest applicable constraint and using 1400 bytes as a recommended maximum when no smaller bound governs. It also notes that fragmented DNS/UDP responses create resilience and cache-poisoning concerns.

The document leaves TC's cause and effect unchanged. If a response cannot safely fit, truncation can still direct the requestor away from a fragile datagram. If fragmented responses disappear before any useful reply arrives, the requestor should eventually try an alternative transport.

This is not proof that TCP will always succeed. It can encounter blocked ports, overloaded servers or its own path problems. It is proof of a more durable idea: a protocol should expose when its evidence is incomplete and preserve a different path for obtaining the whole answer.

What the bit never proved

TC=1 is not a DNSSEC verdict. It does not prove censorship, attack, non-existence, misconfiguration or ownership. It does not authorize a proxy to remove records, and it does not say that every omitted Additional-section RRset made the core answer unusable.

It also does not make TCP the only conceivable larger channel. RFC 2181 used TCP as an example of a mechanism that permits larger replies; subsequent DNS transports add other choices. The invariant is not the name of the transport. It is that incomplete required data cannot be treated as complete.

That invariant is why the one-bit admission survived changes in packet size, security material and transport practice. The Internet did not need every answer to fit the first envelope. It needed the envelope to confess when it had failed.

Sources and limits

The original bit and 512-byte UDP limit come from RFC 1035; RRset and client behavior from RFC 2181; the enlarged UDP offer from RFC 6891; current TCP implementation and operating duties from RFC 7766 and RFC 9210; and fragmentation-avoidance guidance from RFC 9715. These standards do not establish current worldwide TC rates, TCP availability, firewall compliance, implementation defaults or resolver success rates.