DNS TTL: quanto tempo realmente demora uma mudança de IP e como se preparar para isso
Publicado em 2026-10-26 por frfrand
Alterar registros DNS sem quebrar um site nem perder tráfego
Você alterou o registro A para o IP do novo VPS, mas alguns usuários ainda estão chegando ao anterior. Nem sempre é que «a Internet demora para saber»: o TTL define por quanto tempo os resolvers podem manter uma resposta, e há outros caches pelo caminho.
Vamos transformar isso em um procedimento que você pode usar em um VPS real. O objetivo é entender por que funciona, como testá-lo e qual problema aparece se uma parte estiver mal configurada.
O que significa DNS TTL e quando você precisa dele
TTL é expresso em segundos e acompanha a resposta DNS. Os resolvers podem manter um valor até seu vencimento, mas o comportamento varia com caches e políticas. Reduzir o TTL logo antes de alterar o IP não elimina um TTL anterior que já foi armazenado em cache.
Antes de alterar qualquer coisa em produção, anote o estado atual: IP, domínio, porta, serviço afetado e hora do último deploy. Uma modificação isolada é fácil de verificar; cinco mudanças simultâneas tornam mais difícil reconstruir o que aconteceu.
Configuração ou comandos de exemplo
dig ejemplo.com A +noall +answer
dig @1.1.1.1 ejemplo.com A +noall +answer
dig @8.8.8.8 ejemplo.com A +noall +answer
# Ver los servidores autoritativos
dig ejemplo.com NS +shortOs domínios, IPs, caminhos e nomes são ilustrativos. Não copie uma configuração inteira sobre a atual sem comparar primeiro. Nos exemplos que incluem portas ou firewall, certifique-se de preservar o acesso administrativo.
Como eu faria passo a passo
- Preparação. Um dia antes de uma migração, baixe o TTL do registro relevante e espere o TTL antigo expirar.
- Passo 2. Prepare o novo VPS com HTTPS, API e dados restaurados antes de alterar o DNS.
- Passo 3. Faça uma sincronização final de dados ou controle as gravações durante a interrupção.
- Passo 4. Altere o registro A/AAAA e verifique servidores autoritativos e resolvers externos.
- Verificação. Mantenha o ambiente anterior disponível durante um período razoável e depois remova-o com cuidado.
Quando terminar, comprove a operação real a partir de outra conexão. Por exemplo, para uma API não basta abrir o navegador: execute uma solicitação de leitura, uma gravação em um banco de teste e consulte os logs do processo.
Exemplo de um projeto de verdade
Uma loja armazena pedidos no PostgreSQL. Se os dois IPs apontarem temporariamente para bancos diferentes, alguns clientes poderão gerar pedidos no servidor antigo. O problema crítico não é apenas o DNS: é evitar a divergência de dados.
A lição é simples: uma configuração de infraestrutura não vive isolada da aplicação. O frontend, o servidor, o banco de dados e os workers se conectam, então medir onde começa a falha é mais útil do que reiniciar tudo.
O erro que evitaria
Não prometa uma propagação universal de «cinco minutos». TTL baixo ajuda, mas o comportamento depende de resolvers e caches. Também não altere apenas o A se existir um AAAA antigo apontando para outro servidor.
Quando trabalha com servidores de clientes, guarde um backup ou procedimento de reversão antes de mudanças que afetem dados, rede ou certificados. E se não souber quais permissões uma operação precisa, evite executar como root apenas para parar de mostrar erros.
Como isso se relaciona com o ArduMaker?
Ao migrar um site para o ArduMaker, prepare o VPS e os serviços antes do DNS e teste por um domínio temporário ou técnica controlada de resolução. Não use produção para descobrir variáveis faltantes.
Em um caso típico, você pode criar um VPS para a aplicação, implantar a partir do Git, associar domínio HTTPS e administrar o backend e os bancos de dados necessários. As ferramentas ajudam a centralizar operações, mas é preciso entender qual porta e processo cumpre cada função.
Perguntas que aparecem quando você testa
Como saber se a falha é de DNS ou do serviço? Consulte primeiro a resolução, depois a conexão na porta e, finalmente, a resposta da aplicação. Essa ordem evita confundir problemas diferentes.
Posso expor um banco de dados para facilitar a manutenção? Melhor projetar acesso privado ou túneis autenticados quando possível. Expor uma porta não substitui as permissões do mecanismo nem o firewall.
O que devo documentar? A configuração esperada, como verificar e como voltar ao estado anterior. Esse documento ajuda mais do que uma lista de comandos sem contexto.
Referências
Em resumo: uma boa configuração de rede ou servidor é aquela que você consegue explicar, verificar e recuperar quando algo falha.