Como Falhas de DNS Causam Downtime Invisível

Se você já esteve de sobreaviso por tempo suficiente, conhece a sensação. Os alertas do PagerDuty acendem, os dashboards ficam vermelhos e os clientes inundam os canais de suporte. Seu banco de dados está saudável. Seus servidores de aplicação estão rodando. Os balanceadores de carga relatam zero conexões perdidas.

Então, o que está fora do ar exatamente?

Muitas vezes, não é sua infraestrutura. É o tecido conectivo que leva o tráfego à sua porta: o DNS. Tudo parece saudável até que o tráfego desaparece. Falhas de DNS raramente são óbvias porque residem nas camadas entre o usuário e a sua borda. Vamos detalhar por que isso acontece e como verificar sua arquitetura de fora para dentro.

A Ilusão do Uptime Local

A maioria das configurações de monitoramento sofre de “cegueira de dentro para fora”. Seus serviços internos pingam uns aos outros usando IPs privados ou resolução local da VPC. Eles relatam 100% de tempo de atividade porque, dentro do jardim murado do seu provedor de nuvem, eles conseguem se comunicar perfeitamente.

Mas, da perspectiva do usuário, acessar seu site é uma jornada de várias etapas pela lista telefônica da internet pública. Se essa resolução falhar, seu painel de métricas internas ficará alegremente verde enquanto sua receita cai para zero.

Mergulho Técnico: A Cadeia de Resolução de DNS Recursiva

Para entender por que o DNS falha, você precisa entender como ele resolve. Quando um usuário digita sua URL, o dispositivo dele não “sabe” simplesmente seu IP. Ele inicia uma jornada recursiva pelo globo:

1. O Stub Resolver

O SO do cliente pergunta ao DNS configurado (geralmente um provedor de internet ou 1.1.1.1). Essa é a “Primeira Milha” do DNS.

2. O Resolver Recursivo

O resolver do provedor verifica seu cache. Se estiver vazio, ele consulta os Servidores de Nome Raiz para a localização do TLD.

3. Os Servidores de Nome TLD

A raiz aponta o resolver para os servidores de nome .com ou .io. Estes são gerenciados no nível do registro.

4. O Servidor de Nome Autoritativo

Finalmente, a requisição atinge seu provedor de DNS (ex: Route53, Cloudflare). Somente então o registro IP final é retornado ao usuário.

Cada um desses saltos é um ponto de falha potencial. Se seus servidores autoritativos estiverem dropando pacotes, o resolver recursivo pode estourar o tempo limite (timeout) e retornar um SERVFAIL. Pior ainda, se um servidor TLD tiver dados antigos, seu tráfego será enviado para o vazio.

Modos Comuns de Falha de DNS em Produção

Downtime raramente é causado por uma falha isolada. No DNS, costuma ser uma sequência em cascata de eventos:

Modo de Falha	Sintoma	Método de Detecção
Paralisia de TTL	Correções demoram mais de 24h	Monitoramento de Serial Number
Drift de Registro	IPs incorretos em certas regiões	Checagem Autoritativa Global
Queda de TLD	SERVFAIL global total	Validação Recursiva Sintética

O Incidente DDoS da Dyn em 2016

Em 2016, um ataque DDoS massivo contra a Dyn DNS (um provedor autoritativo) derrubou o Twitter, Netflix e GitHub. O ataque não visava as empresas; visava os servidores de nome do provedor. O resultado? Resolvers recursivos globais não conseguiram encontrar a fonte autoritativa, levando a uma cascata massiva de SERVFAIL.

Como Depurar Problemas de Resolução de DNS

Quando suspeitar de um problema de DNS, pare de usar o navegador. Você precisa falar diretamente com as fontes autoritativas. Aqui está o caminho de diagnóstico padrão:

Verifique a Resposta Autoritativa

Use dig para consultar seus servidores de nome diretamente. Isso ignora qualquer cache de provedor:

dig @ns1.your-dns-provider.com seu-dominio.com A

Isole os Gargalos com Trace

Use dig +trace para ver exatamente onde a cadeia de resolução quebra:

dig seu-dominio.com +trace

Monitore Erros e Latência de DNS

Uma prática madura de SRE exige o monitoramento de sinais específicos de DNS. Valide a latência p99 e as taxas de erro a partir de múltiplos pontos de vista globais.

Reforçando sua Infraestrutura de DNS

Trate a infraestrutura de DNS com o mesmo rigor que seu banco de dados primário.

Conclusão

O DNS é chato até quebrar sua empresa. Ferramentas como o Heimdall Observer existem para detectar esses modos de falha antes que causem impacto nos seus usuários.