DNS na prática: quando tudo para de funcionar por causa de um registro
Um registro DNS errado derrubou acesso de email de um escritório inteiro por horas. O problema não estava onde todo mundo estava procurando.
Email de um escritório parou de funcionar às 9h de uma segunda-feira.
Não era o servidor — servidor estava de pé, respondendo, log limpo. Não era autenticação — usuários conseguiam logar no webmail acessando por IP direto. Não era a rede interna — ping funcionava, HTTP funcionava.
Três horas de investigação. A resposta estava num registro MX.
DNS é o serviço que traduz nome em endereço. mail.empresa.com → 192.168.1.50. Parece simples. A maioria das pessoas só pensa em DNS quando algo quebra — e quando quebra, o sintoma raramente aponta para DNS porque DNS é invisível quando funciona.
Registro MX diz para onde email deve ser entregue. Alguém tinha feito uma alteração de DNS na véspera — migração parcial de um domínio — e o registro MX ficou apontando para servidor que não existia mais.
Email enviado para @empresa.com chegava no servidor de DNS, que olhava o MX, que apontava para lugar nenhum. Erro de entrega. Silencioso para quem enviou, invisível para quem esperava receber.
O que aprendi sobre DNS nesse dia e nos seguintes:
TTL não é opcional. Time-to-live determina quanto tempo servidores DNS ao redor do mundo vão cachear aquele registro. Se você muda um registro com TTL de 86400 (24 horas), a mudança leva até 24 horas para propagar. Se você vai fazer migração, reduza o TTL dias antes — para 300 ou 600 — espera propagar, faz a mudança, aumenta o TTL de volta.
dig é ferramenta de diagnóstico, não de configuração. dig MX empresa.com mostra o que o DNS está respondendo agora. dig MX empresa.com @8.8.8.8 pergunta especificamente para o DNS do Google. Se os dois respondem diferente, você tem propagação incompleta.
Problemas de DNS parecem problemas de outra coisa. Email que não chega parece problema de email. Site que não abre parece problema de servidor. VPN que não conecta parece problema de rede. A primeira pergunta agora sempre é: "quando foi a última mudança de DNS?"
Engenheiro de software que não entende DNS vai debugar no lugar errado.
Quando fetch('https://api.exemplo.com') falha, o erro pode estar na aplicação, no servidor, na rede — ou no DNS que não está resolvendo o nome corretamente. Se você só sabe olhar para o código, você perdeu uma categoria inteira de possibilidades.
nslookup, dig, entender o que é A record, CNAME, MX, TXT — isso não é conhecimento de especialista em redes. É conhecimento base de quem opera software em produção.
Essa semana: qual é o último problema que você teve que demorou para resolver porque o sintoma apontava para uma camada e o problema estava em outra?