Uma pesquisa DNS pode falhar porque a resposta não se ajusta à troca UDP utilizável e o caminho de fallback não pode ser concluído. Grande Registros TXT, DNSSEC a composição do material e da resposta pode expor esse problema. Não remova uma chave ou reduza a política apenas porque um verificador não reporta nenhum registro; primeiro determine se o resolvedor obteve uma resposta completa.
Leia o sinal de truncamento
Referências: RFC 1035 §4.1.1, RFC 7766 §5, RFC 6891 §6.2.3.
O bit TC do cabeçalho DNS indica truncamento. Um cliente que precisa dos dados ausentes normalmente tenta novamente usando TCP. As implementações modernas DNS devem suportar TCP sob RFC 7766 ; DNS não é um serviço somente UDP. O EDNS permite que um solicitante anuncie um tamanho de carga UDP maior, mas esse anúncio não é uma garantia de que todas as redes no caminho transportarão o pacote.
Fragmentação de IP, firewalls e middleboxes quebradas podem interferir em respostas UDP maiores. O TCP pode ser necessário independentemente de um determinado valor TXT aparecer pequeno em um painel da web. Meça a resposta e o caminho, não apenas o número de caracteres colados.
Separe as duas pernas do resolvedor
Referências: RFC 7766 §5, RFC 7208 §4.4.
As trocas stub para recursivas e recursivas para autoritativas são distintas. O TCP bem-sucedido do seu laptop para um resolvedor público não prova que o resolvedor do destinatário do email possa alcançar sua autoridade sobre o TCP. Da mesma forma, um teste de autoridade direto não reproduz todos os resolvedores de encaminhamento usados por um receptor.
Registre o proprietário da consulta, tipo, servidor, transporte, opções de EDNS, tamanho da resposta, sinalizadores e tempo. Uma resposta parcial truncada não deve ser interpretada como um conjunto completo de respostas selecionadas. SPF políticas. SERVFAIL e timeout não são evidências de que o nome não existe. Preserve o erro exato antes de alterar os registros do aplicativo.
Reproduzir uma falha de fallback controlada
Em um laboratório DNS descartável, configure uma resposta grande o suficiente para exceder um tamanho de resposta UDP aceito deliberadamente pequeno. Primeiro permita UDP e TCP. Solicite o mesmo proprietário e digite e capture pacotes ou um rastreamento do resolvedor. A evidência esperada inclui uma resposta UDP truncada seguida por uma resposta TCP bem-sucedida quando o cliente executa o fallback.
Em seguida, bloqueie apenas o caminho TCP do laboratório no limite escolhido. Repita a consulta com entrada idêntica e estado de cache controlado. O resultado esperado é uma pesquisa completa com falha nesse limite, apesar de uma troca UDP funcional. Restaure a regra imediatamente após o teste. Esta é uma especificação de laboratório, não uma permissão para alterar a segurança da rede de produção; esse procedimento baseado em firewall não foi executado para este artigo. O experimento histórico de fechamento de serviço abaixo é um teste diferente e mais restrito.
Com uma versão dig do BIND instalada suportando essas opções, cavar @AUTH PROPRIETÁRIO TXT +bufsize=512 +ignorar pode expor a resposta UDP sem nova tentativa automática de TCP, enquanto cavar @AUTH PROPRIETÁRIO TXT +tcp solicita TCP explicitamente. Substitua os valores de laboratório, inspecione a ajuda da versão e retenha o resultado completo. Os comandos não foram executados aqui nesta revisão. A captura de cliente personalizado retida não valida o comportamento de escavação.
Reparar o transporte antes de redesenhar a política
Referências: RFC 7766 §5, RFC 7208 §3.2, RFC 7208 §3.3.
Confirme se o serviço atende ambos os transportes e se o caminho de rede autorizado permite o tráfego necessário. Peça ao operador responsável que revise as alterações no firewall ou no balanceador de carga. Teste novamente a mesma resposta e capture a conclusão no caminho pretendido.
Manter as respostas operacionalmente gerenciáveis é útil, mas dividir um valor TXT em strings dentro de um registro não reduz inerentemente a resposta DNS total o suficiente para resolver falhas de transporte. A divisão de uma política SPF em vários registros de política cria uma violação de padrões separada. Encerre o problema com evidências de transporte e, em seguida, resultados de autenticação representativos, e não com um valor de painel de aparência mais curto.
Evidências históricas de laboratório retidas
A captura retida é datada de 7 de novembro de 2026. A seguir descreve-se essa observação histórica limitada, não uma nova execução ou um teste de EmailAuth.ai .
O serviço DNS isolado emitiu deliberadamente TC com uma resposta UDP vazia para uma resposta TXT grande. A mesma pergunta sobre TCP retornou a resposta completa com TC limpo e um comprimento de fio superior a 512 bytes. Fechar conexões TCP aceitas no serviço de teste causou falha no cliente. Nenhuma configuração de firewall ou rede de produção foi alterada. Isso testa as trocas reais de UDP e TCP sob truncamento forçado; ele não pretende testar o limite de tamanho automático de um servidor DNS ou a implementação de fallback do próprio dig. Os rótulos de captura são large_udp_truncated; large_tcp_complete; tcp_failure.json. O corredor retido e as capturas brutas estão incluídos neste pacote de revisão como evidência histórica. Eles foram inspecionados e não repetidos para esta revisão. Os resultados de DNS de produção, DNSSEC e SMTP permanecem não testados.