Antes de mudar o DNS, baixe o TTL. Depois, suba de novo

O site foi para o servidor novo, o registro A já aponta para o IP novo e metade dos clientes ainda cai no antigo. A equipe acha que a mudança falhou. Ela não falhou, está lenta por configuração. A resposta curta: o TTL do registro diz por quantos segundos os resolvedores podem guardar a resposta. Se ele é de um dia, a troca leva até um dia. Reduza o TTL para alguns minutos com antecedência maior que o TTL antigo, faça a troca, mantenha o servidor antigo funcionando por um tempo e, quando tudo estabilizar, volte o TTL para um valor folgado.

Não existe "propagação" acontecendo por conta própria. Existe cache, com o prazo que você mesmo publicou.

Por que a troca de DNS demora

Quando alguém acessa loja.exemplo.com.br, o computador pergunta a um resolvedor recursivo, normalmente o do provedor de internet ou um público como 1.1.1.1 e 8.8.8.8. Esse resolvedor pergunta aos servidores autoritativos do seu domínio, recebe a resposta e guarda em cache pelo número de segundos indicado no TTL. Durante esse tempo, qualquer outra pessoa que use o mesmo resolvedor recebe a resposta guardada, sem consultar os autoritativos de novo.

A armadilha é que mudar o TTL também é uma mudança de DNS sujeita ao cache. Se o registro tinha TTL de 86400 segundos, um dia, e você baixa para 300 agora, quem guardou a resposta há uma hora vai continuar com ela, e com o TTL antigo, por mais vinte e três horas. Por isso a redução precisa acontecer pelo menos um TTL antigo antes da troca.

Há ainda caches fora do DNS. Sistemas operacionais e navegadores guardam respostas por conta própria. Aplicações com conexões persistentes, como pools de conexão com banco de dados ou serviços que resolvem o nome uma vez ao iniciar, podem continuar falando com o IP antigo até serem reiniciadas. E alguns resolvedores impõem um TTL mínimo próprio, ignorando valores muito baixos. O TTL curto reduz a janela, mas não zera.

Como planejar a troca, com horário

Exemplo trabalhado: o registro A de loja.exemplo.com.br tem TTL de 86400 e a troca está marcada para quinta às 22h.

1. Terça, 22h: baixe o TTL do registro para 300 segundos, cinco minutos, sem mudar o IP. Faça o mesmo nos outros registros que vão mudar.
2. Quarta, 22h ou depois: o TTL antigo de um dia já expirou em todos os caches. Confira com dig que os resolvedores públicos mostram TTL de no máximo 300.
3. Quinta, antes das 22h: teste o servidor novo forçando o IP, sem depender do DNS.
4. Quinta, 22h: troque o IP do registro. Em cerca de cinco minutos, a maioria dos clientes já chega no servidor novo.
5. Quinta e sexta: mantenha o servidor antigo no ar e funcionando, por causa dos caches que não respeitam o TTL. Acompanhe o log de acesso dele até o tráfego cair a quase zero.
6. Depois de estabilizar: volte o TTL para um valor folgado, como 3600 ou mais.

A volta do TTL não é detalhe. Com TTL de 300, cada resolvedor consulta seus autoritativos a cada cinco minutos. Se o provedor de DNS tiver um problema, os caches esvaziam rápido e o site sai do ar para todo mundo. Com TTL de algumas horas, uma falha curta no DNS passa despercebida. TTL baixo é ferramenta de manutenção, não configuração permanente.

Se o servidor antigo tiver dados que mudam, como pedidos, cadastros ou uploads, decida antes o que acontece com quem ainda chega nele durante a janela: modo somente leitura, redirecionamento ou sincronização. Senão você termina com pedidos gravados no banco errado.

Como conferir o TTL e a resposta com dig

# quem são os servidores autoritativos
dig NS exemplo.com.br +short

# a resposta direto da fonte, sem cache
dig @ns1.provedor-dns.exemplo loja.exemplo.com.br A +noall +answer

# o que dois resolvedores públicos têm em cache agora
dig @1.1.1.1 loja.exemplo.com.br A +noall +answer
dig @8.8.8.8 loja.exemplo.com.br A +noall +answer

Na resposta, o número entre o nome e o tipo é o TTL. No autoritativo, ele mostra o valor configurado. No resolvedor, mostra quanto falta para aquela cópia expirar, contando para baixo a cada consulta. Se o resolvedor mostra 70000 dois dias depois de você baixar para 300, o registro que você editou não é o que está sendo servido. Talvez a zona esteja em outro provedor.

Para testar o servidor novo antes da troca, force o IP no teste. Com curl, curl -I --resolve loja.exemplo.com.br:443:198.51.100.20 https://loja.exemplo.com.br/ vai ao IP novo com o nome e o certificado certos. Garanta também que o servidor novo responde pelo nome, como mostra nomes de servidor no nginx.

Os registros que ninguém lembra

A troca de servidor raramente é só o registro A. Faça a lista completa antes de começar: AAAA, se houver IPv6, que costuma ficar esquecido apontando para a máquina antiga; o www, que pode ser CNAME ou outro A; MX e os TXT de SPF, se o e-mail sai pela mesma máquina; e subdomínios de API, painel e arquivos estáticos. Se a troca envolve e-mail, o SPF precisa incluir o IP novo antes da virada, assunto de servidor de e-mail próprio.

Trocar de provedor de DNS, mudando os servidores NS no registro do domínio, é outro caso. A delegação fica na zona do registro, como o Registro.br para domínios .br, com TTL que você não controla. Nessa situação, monte a zona completa no provedor novo, idêntica à antiga, antes de trocar os NS, e mantenha a antiga funcionando por alguns dias.

Erros comuns

• Baixar o TTL na hora da troca. Quem já tinha a resposta em cache segue com o TTL antigo, e a janela continua sendo de um dia.
• Desligar o servidor antigo logo após a troca. Quem ainda está no cache antigo, ou atrás de um resolvedor que ignora TTL, encontra o site fora do ar.
• Esquecer de subir o TTL depois. O domínio fica dependente de o provedor de DNS responder a cada poucos minutos, e uma falha curta vira queda.
• Trocar só o registro A. O AAAA continua apontando para a máquina velha e usuários com IPv6 caem nela sem ninguém entender por quê.
• Testar no próprio navegador. O cache do sistema e do navegador mostram o resultado antigo, ou o novo, sem relação com o que os clientes veem.
• Esquecer as aplicações com conexão persistente. Serviços que resolveram o nome ao iniciar continuam falando com o IP antigo até um reinício.

Checklist

• Existe a lista completa de registros que vão mudar, incluindo AAAA, www, MX e TXT.
• O TTL foi reduzido pelo menos um TTL antigo antes da troca.
• O dig nos resolvedores públicos mostra o TTL novo antes da virada.
• O servidor novo foi testado com o nome forçado para o IP novo.
• O servidor antigo fica no ar até o tráfego dele zerar.
• Está decidido o que acontece com escritas que chegam no servidor antigo.
• O TTL volta para um valor folgado depois da estabilização.

Rode um dig no registro principal do seu site agora. Se você precisasse trocar o IP hoje à noite, por quanto tempo o endereço antigo ainda estaria nos caches?