Como Falhas de DNS Causam Downtime Invisível | Heimdall Monitor
Pular para o conteúdo

Como Falhas de DNS Causam Downtime Invisível

Falhas de DNS são frequentemente invisíveis. Aprenda como cadeias de resolução recursiva e latência podem derrubar sua infraestrutura silenciosamente.

D
Daniel Morgan
8 de mar. de 20264 min de leitura
Como Falhas de DNS Causam Downtime Invisível

Plataformas de observabilidade são projetadas para rastrear o que seus sistemas estão fazendo. Mas o que acontece quando uma falha ocorre antes mesmo de uma requisição alcançar a borda da sua infraestrutura? Seus dashboards reportarão com confiança 100% de uptime, enquanto seus clientes experimentam um blecaute implacável.

O Dilema do 'Split-Horizon'

A razão pela qual suas métricas mentem deve-se à natureza split-horizon de rede em nuvem. Seus pods internos do Kubernetes ou instâncias EC2 resolvem endpoints de serviço internos usando um resolver VPC privado (como o AWS Route53 Resolver). Como a rede interna está perfeita, os health checks entre microsserviços têm sucesso brilhante.

Mas os clientes externos dependem da cadeia de resolução recursiva da internet pública para descobrir seus Ingress voltados para o público.

Quando a Porta da Frente Desaparece

Uma falha 'invisível' acontece quando os registros autoritativos públicos são interrompidos. Um exemplo clássico ocorreu durante a queda do Slack em 2021: uma equipe de engenharia aplicou uma configuração que inadvertidamente removeu todos os registros A para seus domínios principais de API.

Internamente no Slack, os servidores estavam funcionando, processando jobs em background e mantendo conexões websocket abertas. Mas nenhum cliente novo conseguia resolver o domínio 'slack.com' para estabelecer uma conexão. A internet simplesmente esqueceu onde o Slack estava hospedado.

Isolando a Lacuna: Validação Interna vs Externa

Para provar essa discrepância, você pode escrever um script de teste simples. Em vez de confiar em uma ferramenta de ping que usa a configuração padrão do seu SO, você força explicitamente uma consulta DNS contra o servidor autoritativo público do seu domínio:

nslookup -debug seudominio.com ns1.seu-provedor-dns.com

Se esse comando der timeout ou retornar NOERROR com 0 respostas, sua camada de registros autoritativos falhou, independentemente do que o Datadog esteja lhe dizendo.

Criando Contexto Externo de Alta Fidelidade

Derrotar a cegueira de dentro para fora exige implantar sondas fora do seu provedor de nuvem. Nós de monitoramento sintético devem rodar a partir de redes de ISP isoladas, resolvendo repetidamente seu domínio e afirmando que os IPs retornados realmente pertencem ao ASN do seu Load Balancer.

Conclusão

Ao projetar sua postura de confiabilidade, nunca confie em um health check interno para validar a alcançabilidade externa. A internet é uma teia complexa de repasses, e o DNS é o primeiríssimo deles.

Para automatizar essa perspectiva, o Heimdall Observer audita continuamente seus domínios a partir de pontos de vista globais, mapeando sua verdadeira saúde de resolução pública.

0 acharam útil
D
Escrito por Daniel Morgan

Engenheiro de infraestrutura focado em DNS, redes e nas camadas invisíveis que determinan se as aplicações são alcançáveis.

"Criamos o Heimdall Observer para solucionar os problemas discutidos neste artigo."