“Sempre é Culpa do DNS”: Como uma Atualização Derrubou a AWS e Metade da Internet

Há um poema antigo e infame que circula entre os engenheiros de confiabilidade de sites (SREs):

> “Não tem como ser o DNS.
> Não tem como ser o DNS.
> Era o DNS.”

Quando a Amazon Web Services (AWS) sofreu um de seus maiores apagões históricos, o planeta inteiro sentiu o impacto: plataformas de streaming travaram, bancos digitais pararam, entregas foram interrompidas e até aspiradores de pó inteligentes e fechaduras residenciais deixaram de responder.

E a causa raiz não foi um ataque hacker sofisticado ou um desastre físico em um datacenter: foi uma atualização rotineira no sistema interno de DNS.

Neste post-mortem aprofundado, desvendamos como uma simples alteração de registros causou um efeito dominó catastrófico na maior nuvem do planeta — e quais lições de arquitetura você deve aplicar no seu próprio sistema para não ser vítima da próxima tempestade.

⚡ Anatomia do Desastre em 30 Segundos (TL;DR)

🌪️ O Efeito Dominó: Como o DNS Destruiu a Nuvem por Dentro

A arquitetura da AWS é composta por milhares de microsserviços autônomos. Quando um servidor EC2 precisa conversar com o banco DynamoDB, gravar um arquivo no S3 ou autenticar uma chamada no IAM, ele não usa um endereço IP fixo: ele faz uma consulta ao DNS interno da AWS.

Veja como o desastre se propagou através de quatro etapas mortais:

A Ilusão do Multi-AZ: Milhares de empresas que pagavam o dobro por arquitetura de Alta Disponibilidade em Múltiplas Zonas de Disponibilidade (Multi-AZ) caíram do mesmo jeito. O DNS interno e o plano de controle da região us-east-1 são compartilhados por todas as zonas.

🛠️ Como Blindar sua Aplicação Contra Falhas de DNS

Se a própria Amazon pode cair por causa de DNS, sua aplicação não pode ser ingênua. Existem duas vacinas obrigatórias de engenharia de software para sobreviver a esse cenário:

1. Implemente Retentativa Exponencial com “Jitter” (Backoff & Jitter)

Nunca deixe sua aplicação tentar reconectar no mesmo segundo em que a falha ocorre. Se 10.000 clientes caírem juntos e tentarem reconectar no mesmo instante, eles realizam um ataque DDoS involuntário no seu próprio servidor.

Veja o algoritmo de Exponential Backoff com Full Jitter em Node.js / TypeScript:

// Implementação de Backoff Exponencial com Jitter Completo
async function fetchWithJitter(url: string, retries = 5, baseDelayMs = 100) {
  for (let attempt = 0; attempt < retries; attempt++) {
    try {
      return await fetch(url);
    } catch (error) {
      if (attempt === retries - 1) throw error;

      // Cálculo do teto exponencial: base * 2^attempt
      const maxDelay = baseDelayMs * Math.pow(2, attempt);

      // Full Jitter: escolhe um valor aleatório entre 0 e maxDelay
      // Isso espalha a carga e impede o efeito manada (Thundering Herd)
      const jitterDelay = Math.random() * maxDelay;

      console.warn(`Tentativa ${attempt + 1} falhou. Aguardando ${jitterDelay.toFixed(0)}ms...`);
      await new Promise((resolve) => setTimeout(resolve, jitterDelay));
    }
  }
}

2. Ative o Cache de DNS Local nas Instâncias Linux

Por padrão, muitos runtimes (incluindo versões antigas do Java e distribuições Linux sem caching local) fazem uma consulta DNS remota a cada requisição HTTP. Se o resolver demorar, sua aplicação trava.

Habilite um resolvedor de cache local com o systemd-resolved ou dnsmasq:

systemd-resolve --status

sudo systemctl restart systemd-resolved

No caso de aplicações Java, configure a JVM para nunca manter cache infinito ou nulo:

networkaddress.cache.ttl=30
networkaddress.cache.negative.ttl=10

💡 4 Lições de Arquitetura que Todo Arquiteto Cloud Precisa Aprender

1. Estabilidade Estática (Static Stability): Seus sistemas devem continuar funcionando mesmo que o plano de controle da nuvem caia. Por exemplo: instâncias que já estão rodando devem continuar processando pedidos mesmo que você não consiga subir novas instâncias.
2. Evite Dependência Absoluta de us-east-1: A região da Virgínia do Norte é a mais antiga da AWS e hospeda a sede de serviços globais (como IAM e faturamento). Considere distribuir cargas críticas para sa-east-1 (São Paulo) ou regiões secundárias.
3. Não confie em Health Checks Ingênuos: Se o seu balanceador de carga falhar na resolução de DNS, configure uma tolerância mínima antes de drenar o tráfego dos servidores operacionais.
4. Métricas Externas Independentes: Nunca use apenas ferramentas hospedadas dentro do mesmo provedor de nuvem para monitorar seu status. Tenha agentes sintéticos externos (Datadog, Pingdom, Zabbix em outro datacenter) testando suas rotas públicas.

Dica de Engenharia Hora Nerd: Em arquiteturas corporativas de missão crítica, utilize a técnica de Cell-Based Architecture (Arquitetura Celular), dividindo o tráfego em ilhas independentes onde um erro de resolução em uma célula nunca contamina as outras.

❓ Perguntas Frequentes (FAQ)

Por que a AWS não usa IPs fixos para tudo em vez de nomes de DNS?
Em escala planetária, com milhões de servidores nascendo e morrendo a cada minuto (containers, lambdas, instâncias spot), é fisicamente impossível gerenciar redes usando IPs fixos. O DNS é a única camada que oferece a abstração necessária para balanceamento de carga e migração transparente.

O Route 53 público também caiu durante esse incidente?
O serviço de DNS público (autoritativo para domínios externos) possui infraestrutura global distribuída altamente resiliente. O colapso foi focado nos resolvers internos regionais e na orquestração de APIs que dependiam deles para comunicação entre serviços na mesma região.

Gostou deste post-mortem? Aprofunde seus conhecimentos em arquitetura e infraestrutura de alta escala na nossa seção de DevOps e Servidores e consulte nossos Cheatsheets para comandos rápidos.

✓

Guilherme Nascimento

Especialista & Fundador

Especialista em Infraestrutura, Cloud/DevOps e Cibersegurança | +10 anos de experiência prática

Profissional com mais de uma década atuando no campo de batalha da tecnologia corporativa. Especialista em arquiteturas resilientes, automação com Docker/Kubernetes, Hardening de Active Directory, Linux avançado e observabilidade SRE. Criador do ecossistema Hora Nerd, dedicado a desmistificar a tecnologia para profissionais e estudantes.

Cloud & DevOps Active Directory Hardening Linux SysAdmin Docker & CI/CD Observabilidade SRE

Conectar no LinkedIn GitHub