Saiba como falhas no DNS podem derrubar sua aplicação sem gerar alertas tradicionais e como protegê-la.

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 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.
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:
O SO do cliente pergunta ao DNS configurado (geralmente um provedor de internet ou 1.1.1.1). Essa é a “Primeira Milha” do DNS.
O resolver do provedor verifica seu cache. Se estiver vazio, ele consulta os Servidores de Nome Raiz para a localização do TLD.
A raiz aponta o resolver para os servidores de nome .com ou .io. Estes são gerenciados no nível do registro.
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.
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 |
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.
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:
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
Use dig +trace para ver exatamente onde a cadeia de resolução quebra:
dig seu-dominio.com +trace
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.

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.
Junte-se a milhares de equipes que confiam no Heimdall para manter seus sites e APIs online 24/7. Comece com nosso plano gratuito hoje.
Comece a monitorar gratuitamenteEngenheiro de infraestrutura focado em DNS, redes e nas camadas invisíveis que determinan se as aplicações são alcançáveis.