Timeout de DNS vs. SERVFAIL: qual é a diferença?

Nem toda consulta DNS falha do mesmo jeito. Duas das falhas mais comuns além do NXDOMAIN, o timeout e o SERVFAIL, parecem semelhantes vistas de fora (nenhuma resposta utilizável voltou), mas indicam causas raiz bem diferentes.

Timeout: nenhuma resposta chegou a tempo

Um timeout significa exatamente o que o nome diz: a consulta foi enviada e nenhuma resposta voltou dentro do tempo de espera configurado. Isso pode acontecer porque o servidor autoritativo está sobrecarregado, por perda de pacotes em algum ponto do caminho de rede ou porque um firewall está descartando o tráfego de DNS em silêncio, em vez de rejeitá-lo abertamente. Do lado de quem consulta, um timeout e um servidor que simplesmente não existe são idênticos: nos dois casos só há silêncio.

SERVFAIL: chegou uma resposta, e ela foi “não consigo”

O SERVFAIL é uma resposta de verdade, e não silêncio. O servidor que respondeu está dizendo explicitamente que encontrou um problema ao processar a consulta: uma zona mal configurada, uma falha de validação do DNSSEC, um erro interno do lado do resolvedor. Receber um SERVFAIL diz que algo concreto aconteceu no servidor, enquanto um timeout diz comparativamente muito pouco sobre onde o problema realmente está.

Como os dois podem ser transitórios, o tratamento correto para ambos é o mesmo na prática: tentar de novo poucas vezes com backoff exponencial e só informar uma falha real depois que essas tentativas se esgotarem. É exatamente assim que esta ferramenta trata os dois códigos de maneira diferente de um NXDOMAIN definitivo.

REFUSED geralmente indica uma política, não uma falha

O REFUSED costuma ser agrupado com o SERVFAIL porque ambos são “o servidor disse não” em vez de silêncio, mas os motivos por trás deles em geral são bem diferentes. Um servidor de nomes costuma retornar REFUSED quando está configurado para responder apenas por zonas específicas e recebe uma pergunta fora do seu escopo, quando uma lista de controle de acesso bloqueia o IP de quem consulta ou quando um resolvedor foi configurado explicitamente para rejeitar consultas vindas de fora da própria rede (um resolvedor recursivo que se recusa a atender desconhecidos na internet, por exemplo, é um comportamento correto e intencional, não um bug). Quando o REFUSED vem de um servidor que você não controla, dificilmente uma nova tentativa ou uma estratégia de backoff resolverá; vale verificar se você está consultando o servidor certo.

Uma causa comum e específica de SERVFAIL: DNSSEC quebrado

Um dos cenários de SERVFAIL mais frustrantes acontece em domínios com DNSSEC ativado, mas mal configurado: uma assinatura expirada, uma chave trocada no servidor de nomes mas não atualizada no registrador ou uma cadeia de confiança quebrada em algum ponto entre o domínio e a raiz. Um resolvedor com validação, que respeita o DNSSEC, se recusa a devolver uma resposta que não consegue verificar criptograficamente e retorna SERVFAIL em vez de ignorar em silêncio a assinatura quebrada. O mais desconcertante é que o domínio muitas vezes funciona perfeitamente em um resolvedor que não valida o DNSSEC, o que faz essa causa ser facilmente diagnosticada de forma errada como “aqui funciona”, quando na verdade o domínio está quebrado para uma parcela significativa dos visitantes reais.