Resumo

  • TC indica que a mensagem foi truncada porque excedeu o comprimento permitido pelo canal. A RFC 2181 restringiu esse sentido a um RRset necessário que não coube inteiro e orientou o cliente a ignorar a resposta parcial.
  • O TCP serviu à nova tentativa com mais capacidade, mas deixou de ser exceção. A RFC 7766 exigiu UDP e TCP em implementações DNS de uso geral e permitiu começar por TCP; a RFC 9210 transformou passagem, capacidade e monitoramento em obrigações de operação.

O pacote pequeno não podia editar o nome

A RFC 1035, de 1987, colocou DNS em UDP e TCP na porta 53. UDP era atraente para consultas correntes: dispensava conexão e guardava pouco estado. Seu limite original, porém, era de 512 bytes de mensagem DNS, sem contar os cabeçalhos de IP e UDP.

Mensagens maiores eram cortadas e marcadas com TC=1. O bit falava sobre o canal, não sobre o nome. Ele não dizia que certo registro não existia, que a resposta era negativa ou que os itens visíveis formavam uma seleção autorizada.

Essa separação evita que a capacidade física produza um fato lógico. Se cinco endereços pertencem ao mesmo nome e três entram no datagrama, o tamanho do datagrama não ganha autoridade para reduzir o conjunto a três.

O RRset virou a unidade que não se parte

A RFC 2181 esclareceu em 1997 que registros com o mesmo nome proprietário, classe e tipo formam um RRset. Quando esses dados são necessários, o conjunto inteiro é a resposta.

TC deve aparecer se um RRset exigido não puder ser incluído por completo. Se faltar espaço apenas para material adicional, o servidor pode omitir todo esse RRset auxiliar e manter TC limpo. Quem precisar da informação fará outra pergunta.

Quando TC está ativo, o cliente deve ignorar a resposta e consultar novamente por um mecanismo que aceite resposta maior, como TCP. Um pedaço do RRset pode continuar nos bytes recebidos, mas não deve ser juntado ao cache nem promovido a evidência.

O protocolo escolheu perder aquela tentativa em vez de preservar uma falsa certeza. Integridade veio antes do aproveitamento de fragmentos.

O resolvedor ficou com a decisão seguinte

Na sequência conhecida, a consulta sai por UDP, recebe TC e é repetida por TCP. O DNS sobre TCP usa um campo de comprimento antes da mensagem e pode entregar mais do que um único datagrama.

Ainda assim, o bit não abre a conexão nem escolhe toda a política. O resolvedor pode reutilizar uma sessão, procurar outro servidor ou optar por outro transporte; o servidor decide admissão, concorrência e tempo ocioso. Quem paga o estado conserva os controles de recurso.

Esses controles não incluem alterar os dados. O servidor afirma apenas que esta entrega foi incompleta. O consumidor, que precisa da resposta, assume a responsabilidade de buscar a versão inteira.

EDNS aumentou o tamanho oferecido, não a certeza do caminho

A RFC 6891 permitiu ao solicitante anunciar a carga UDP que aceita. EDNS(0) levou muitas respostas além dos 512 bytes sem abandonar UDP.

O valor anunciado num extremo não mede todos os enlaces, túneis e filtros. Fragmentos IP podem sumir ou ser descartados. DNSSEC acrescentou assinaturas e provas; respostas modernas ganharam mais ocasiões para crescer.

EDNS oferece um orçamento. TC relata que o conteúdo necessário não coube no orçamento utilizável. Um número maior não é prova de entrega ponta a ponta. Se o datagrama grande desaparece no caminho, talvez nenhum TC chegue, por isso timeout UDP não pode ser confundido com resposta negativa do DNS.

TCP ganhou lugar normal na arquitetura

Durante anos, a descrição curta dizia que TCP servia para transferência de zona e fallback. Isso ajudou redes a tratar TCP/53 como dispensável, embora a recuperação de respostas truncadas dependesse dele.

A RFC 7766, publicada em 2016, exigiu UDP e TCP em servidores autoritativos e recursivos, encaminhadores e resolvedores locais de uso geral. Também relaxou a antiga regra de começar consultas comuns por UDP: razões operacionais locais podem justificar TCP primeiro, e uma conexão aberta deve ser reaproveitada.

TC continua sendo um gatilho frequente para TCP, não uma ordem universal para todos os casos. TCP é alternativa de primeira classe e transportes DNS posteriores ampliaram o leque. O compromisso está na completude, não numa sequência fixa.

Escalar o fluxo exigiu controlar o estado

Uma conexão nova para cada pergunta repete o custo de handshake. A RFC 7766 recomenda reuso e pipeline: várias consultas podem seguir sem aguardar a resposta anterior; o servidor processa em paralelo e pode responder fora de ordem.

O cliente precisa associar cada resposta à consulta correta. Servidores e monitores precisam reconstruir o stream, porque um segmento TCP não equivale necessariamente a uma mensagem DNS.

Também cabem limites por cliente ou sub-rede, redução de conexões concorrentes e fechamento por ociosidade. Proteger memória, descritores e trabalhadores é legítimo. O que não é legítimo é substituir uma falha explícita por um RRset parcial aceito.

Operar DNS passou a incluir os dois lados

A RFC 9210 determinou que resolutores e servidores atendam UDP e TCP e que redes permitam ambos em geral. Filtrar TCP é danoso porque elimina a rota de recuperação de respostas maiores.

Servidores ainda podem limitar recursos, mas não recusar uma pergunta apenas porque ela teria sucesso em outro transporte. O limite deve acompanhar custo e risco, não criar uma hierarquia arbitrária de verdade.

Monitoramento precisa remontar streams, entender sessões reutilizadas, pipeline e respostas fora de ordem. Quem observa apenas UDP não sabe se a admissão de incompletude terminou em resposta completa ou em falha silenciosa.

Evitar fragmentação preservou o antigo sinal

A RFC 9715, de 2025, recomenda evitar fragmentação IP em DNS/UDP e usa 1400 bytes como máximo recomendado quando nenhum limite menor se aplica. Fragmentação reduz resiliência e pode favorecer envenenamento de cache.

O efeito de TC permanece. Se a resposta não cabe com segurança, o servidor pode marcá-la; se fragmentos somem, o solicitante deve acabar tentando outro transporte. TCP também pode ser bloqueado ou sobrecarregado, mas a arquitetura mantém o princípio de não chamar ausência de bytes de resposta completa.

O bit nunca afirmou mais do que sabia

TC não prova falha de DNSSEC, censura, ataque, inexistência ou propriedade. Nem toda omissão da seção Additional exige truncamento, e TCP não é o único transporte maior possível.

A alegação estreita é justamente a confiável: esta entrega não trouxe tudo o que a pergunta exigia. O DNS aceitou uma primeira rota barata e limitada; não aceitou que essa limitação se passasse pela verdade do namespace.

Fontes e limites

A base histórica vem da RFC 1035, a integridade do RRset da RFC 2181, EDNS da RFC 6891, os deveres TCP das RFC 7766 e RFC 9210, e a orientação sobre fragmentação da RFC 9715. Elas não medem taxas globais atuais de TC, bloqueio ou sucesso.