Você migra um site, tudo parece certo do seu lado, e então as mensagens começam a chegar. Alguns visitantes veem o novo site, outros ainda estão acessando o antigo, e alguns relatam erros que você não consegue reproduzir.
Quando isso acontece, é fácil culpar o provedor de hospedagem ou a migração em si. Na maioria das vezes, porém, a causa real é o DNS, não porque está com defeito, mas porque está fazendo exatamente o que foi projetado para fazer.
As atualizações de DNS não acontecem todas de uma vez. Elas dependem de camadas de cache e resolvedores fora do seu ambiente de hospedagem, o que explica por que as migrações podem parecer imprevisíveis mesmo quando o site já está pronto.
Este guia explica o que o DNS realmente controla, por que a propagação se comporta de forma diferente para pessoas diferentes e como planejar uma migração para que o DNS seja uma etapa final controlada, em vez de uma fonte de tempo de inatividade ou confusão.
O que o DNS realmente faz
O DNS responde a uma pergunta muito específica: Para onde este domínio deve apontar?
Quando alguém digita seu domínio em um navegador, o DNS traduz esse nome em um endereço IP. Esse endereço IP indica ao navegador a qual servidor se conectar. O DNS não carrega páginas nem se importa com o que está sendo executado no servidor. Ele apenas cuida da consulta.
Para que essa consulta funcione de forma confiável, o DNS é dividido em algumas partes separadas, cada uma com um papel bem definido.
- Registrador de domínio: Seu registrador é onde o domínio é adquirido e renovado. Ele não hospeda seu site nem controla o tráfego. Do ponto de vista do DNS, sua principal responsabilidade é apontar o domínio para os servidores de nomes corretos.
- Provedor de DNS autoritativo: É o serviço que armazena seus registros DNS e fornece a resposta final quando a internet pergunta para onde seu domínio deve resolver. Provedores como o Cloudflare ou sua plataforma de hospedagem frequentemente assumem esse papel.
- Servidores de nomes: Os servidores de nomes informam à internet qual provedor de DNS é autoritativo para o seu domínio. Eles não contêm dados ou configurações do site em si. Eles simplesmente direcionam as consultas DNS para o lugar certo.
- Registros DNS (A, AAAA, CNAME): Esses registros definem para onde o tráfego vai. Os registros A apontam um domínio para um endereço IPv4, os registros AAAA apontam para um endereço IPv6, e os registros CNAME criam um alias de um domínio para outro.
Juntos, esses registros determinam qual servidor os visitantes acessam ao carregar seu site.
Tão importante quanto isso é o que o DNS não faz. O DNS não serve arquivos, não move bancos de dados, não sincroniza conteúdo nem gerencia certificados SSL. Ele nunca mexe no seu ambiente de hospedagem.
Uma vez que esse limite fica claro, o resto do processo de migração fica muito mais fácil de entender.
O que muda durante a migração de um site e o que permanece igual
Um dos motivos pelos quais o DNS causa tanta confusão durante migrações é que apenas uma pequena parte da configuração realmente muda. O restante permanece exatamente como estava antes, mesmo que o site em si esteja sendo transferido para um ambiente completamente novo.
Durante uma migração típica de site, algumas coisas geralmente mudam.
- O endereço IP quase sempre muda porque o site agora está em um servidor diferente. Essa é a atualização relacionada ao DNS mais comum e a que, em última análise, direciona o tráfego para o destino correto.
- O ambiente de hospedagem também muda. Isso inclui o servidor, a infraestrutura e a plataforma que executa seu site. Embora isso afete o desempenho e a estabilidade, é algo separado do DNS e deve estar totalmente pronto antes de qualquer atualização de DNS.
- Em muitos casos, registros DNS específicos mudam. Os registros A ou AAAA são atualizados para apontar para o novo endereço IP. Às vezes, os registros CNAME são ajustados, dependendo de como o site está configurado.
Ao mesmo tempo, várias coisas geralmente permanecem as mesmas.
- O nome de domínio não muda. Os visitantes continuam digitando a mesma URL, e nada no endereço público precisa ser atualizado.
- Os servidores de nomes também permanecem os mesmos, a menos que você esteja intencionalmente trocando de provedor de DNS. A maioria das migrações não exige nenhuma alteração nos servidores de nomes, mesmo quando o provedor de hospedagem muda.
É por isso que o DNS é quase sempre a última etapa de uma migração. Você monta e verifica o novo ambiente primeiro, depois atualiza o DNS quando tudo estiver pronto para receber tráfego.
Tratar o DNS como uma etapa final controlada, em vez de uma tarefa inicial, reduz a incerteza, limita a exposição e torna o tempo de inatividade muito mais fácil de evitar.
Propagação de DNS e por que é imprevisível
A propagação do DNS não significa que a internet está “atualizando” seu domínio de uma só vez. Ela descreve quanto tempo leva para que as alterações no DNS sejam captadas, armazenadas em cache e reutilizadas em muitos sistemas independentes.
Quando alguém acessa seu site, a solicitação não vai diretamente ao seu provedor de DNS toda vez. Ela geralmente passa por um resolvedor recursivo, frequentemente operado por um provedor de internet, uma rede corporativa ou um serviço público como o Google ou o Cloudflare. Esse resolvedor consulta o provedor de DNS autoritativo para obter uma resposta e, em seguida, armazena o resultado para uso posterior.
Depois que um resolvedor armazena uma resposta DNS em cache, ele continua usando essa resposta até o cache expirar. É aqui que entra a imprevisibilidade. Diferentes resolvedores armazenam dados DNS em cache por períodos diferentes. Alguns respeitam os valores de TTL com precisão. Outros aplicam seus próprios limites ou reutilizam dados em cache por mais tempo do que o esperado.
Além disso, os caches do navegador e do sistema operacional podem armazenar resultados de DNS localmente. Mesmo que o registro DNS global já tenha sido atualizado, o dispositivo do usuário pode continuar usando uma resposta mais antiga até que o cache local seja limpo ou expire.
Esse cache em camadas explica por que duas pessoas em locais diferentes podem ver versões diferentes do mesmo site ao mesmo tempo. Um resolvedor tem o novo endereço IP. Outro ainda está apontando para o servidor antigo.
A regra comum de “24 a 48 horas” simplifica demais o que realmente está acontecendo. Muitos usuários veem as atualizações em minutos. Outros podem não vê-las por muito mais tempo, dependendo do comportamento do resolvedor e dos caches locais.
TTL e como ele ajuda a evitar tempo de inatividade
O TTL, ou Time to Live, controla por quanto tempo as respostas DNS ficam armazenadas em cache antes que um resolvedor solicite informações atualizadas. Ele não força as atualizações a acontecerem mais rapidamente, mas limita por quanto tempo informações desatualizadas podem ser reutilizadas.
Cada registro DNS tem seu próprio valor de TTL, medido em segundos. Se um registro tem um TTL de 300, os resolvedores podem reutilizar essa resposta por até cinco minutos antes de verificar novamente. Um TTL de 86.400 permite o armazenamento em cache por um dia inteiro.
É por isso que reduzir o TTL antes de uma migração é importante. Se os resolvedores já estiverem armazenando respostas DNS de curta duração, eles serão atualizados com mais frequência quando você alterar os registros. Isso reduz a janela em que os visitantes podem ser direcionados ao servidor antigo após a troca.
Para a maioria das migrações, um TTL entre 300 e 600 segundos é um bom equilíbrio. É curto o suficiente para limitar os atrasos de propagação sem sobrecarregar desnecessariamente a infraestrutura de DNS.
Ir muito abaixo pode causar problemas. TTLs extremamente curtos não garantem atualizações instantâneas, e alguns resolvedores ignoram valores incomumente pequenos. Outros podem limitar a taxa de solicitações ou voltar a usar dados em cache de qualquer forma. Reduzir o TTL de última hora é outro erro comum. Se os caches já armazenam registros de longa duração, alterar o TTL não os afetará até que esses caches expirem.
A abordagem mais segura é o momento certo. Reduza o TTL pelo menos 24 horas antes da migração, confirme que o novo valor está ativo e só então agende a alteração de DNS.
Um cronograma seguro de migração de DNS (passo a passo)
Uma migração de DNS tranquila prioriza o sequenciamento em vez da velocidade. Quando cada etapa acontece na ordem correta, o DNS se torna uma troca controlada em vez de um jogo de adivinhação. Veja como fazer isso com sucesso:
1. Prepare o novo ambiente de hospedagem
Configure o novo site completamente antes de tocar no DNS. Isso inclui instalar dependências, configurar o cache, definir redirecionamentos e verificar o desempenho.
Teste o site usando uma URL temporária ou um arquivo hosts local para que você possa visualizá-lo como se o DNS já apontasse para o novo servidor. Certifique-se de que os certificados SSL estejam prontos e válidos, especialmente se o HTTPS for obrigatório. O DNS nunca deve ser a etapa em que você descobre problemas de configuração.
Você pode ajustar as informações de DNS no MyKinsta facilmente acessando seu painel de controle, clicando em DNS e depois em Adicionar seu primeiro nome de domínio.
2. Reduza o TTL com antecedência
Reduza os valores de TTL nos registros DNS relevantes bem antes da migração. O ideal é fazer isso pelo menos 24 horas antes da mudança planejada.
Após alterar o TTL, confirme que o novo valor está ativo usando ferramentas de consulta DNS. Isso garante que os resolvedores comecem a armazenar em cache respostas de vida mais curta antes que qualquer alteração de IP ocorra.
3. Congele alterações arriscadas
Pause edições de conteúdo, pedidos de eCommerce e envios de formulários se o site depende de um único banco de dados. O DNS não move dados, portanto, alterações feitas no site antigo após o snapshot da migração podem ser perdidas.
4. Atualize os registros DNS
Altere apenas os registros que precisam de atualização, geralmente registros A, AAAA ou CNAME apontando para o site. Evite modificar registros não relacionados durante a mesma janela. Você também pode ajustar essas informações no MyKinsta. Na mesma página de DNS mencionada anteriormente, role para baixo até Registros DNS e selecione Adicionar um registro DNS para inserir essas informações manualmente.
Verifique os endereços IP, tipos de registros e hostnames para evitar conflitos. Após a atualização, verifique as alterações usando consultas DNS diretas, não apenas testes no navegador.
Você também pode realizar uma varredura automática dos registros DNS clicando em Iniciar varredura em Varredura automática.
5. Monitore a propagação em tempo real
De onde vem o tempo de inatividade e como evitá-lo
Quando o tempo de inatividade ocorre durante uma migração, o DNS frequentemente leva a culpa. Na prática, a causa raiz geralmente está em outro lugar.
Os problemas de DNS tendem a ser simples e binários: um registro aponta para o lugar certo ou não aponta. A maioria das interrupções vem de lacunas entre DNS, hospedagem e a própria aplicação.
- Um ponto de falha comum é um endereço IP incorreto. Um único erro de digitação ou valor desatualizado envia o tráfego para o servidor errado, o que parece tempo de inatividade mesmo que o DNS esteja resolvendo corretamente.
- Registros DNS ausentes ou incompletos causam sintomas semelhantes. Registros de e-mail, subdomínios www ou registros de verificação às vezes são esquecidos durante as alterações, levando a interrupções parciais ou funcionalidades quebradas.
- O desalinhamento de SSL é outra causa frequente. O DNS pode estar apontando para o novo servidor, mas o certificado não está instalado ou não cobre o domínio correto ainda. Os navegadores bloqueiam o acesso, o que os usuários experimentam como tempo de inatividade.
- O cache também pode trabalhar contra você. Conteúdo ou redirecionamentos em cache podem ainda apontar para o servidor antigo após as atualizações de DNS, especialmente se proxies reversos ou camadas de CDN não estiverem alinhados com o novo ambiente.
A maneira mais confiável de evitar esses problemas é a sobreposição. Mantenha os ambientes antigo e novo ativos ao mesmo tempo, totalmente funcionais, até que o tráfego tenha claramente migrado. Quando ambos os servidores podem atender solicitações com segurança, a propagação de DNS se torna muito menos arriscada.
Como a hospedagem gerenciada reduz o risco relacionado ao DNS
A hospedagem gerenciada pode reduzir o risco de migração ao garantir que o novo ambiente esteja totalmente preparado antes das alterações de DNS. A maioria das plataformas gerenciadas fornece ambientes de teste ou URLs temporárias, pilhas de servidores pré-configuradas e verificações de prontidão de SSL, para que o novo site possa ser testado de ponta a ponta enquanto o site antigo ainda atende os visitantes.
O suporte à migração também desempenha um papel importante. Equipes experientes validam registros DNS, confirmam atribuições de IP e identificam erros de configuração comuns que causam interrupções. Em vez de tentar adivinhar se um problema é de DNS, SSL ou nível de aplicação, os problemas são identificados e resolvidos mais cedo no processo.
A Kinsta estrutura as migrações para que ambientes sobrepostos sejam o padrão. O site antigo continua atendendo o tráfego enquanto o novo site é preparado e verificado. Quando as atualizações de DNS acontecem, ambos os lados estão prontos para lidar com as solicitações.
Mitos sobre DNS que causam pânico desnecessário
Grande parte do estresse com migrações vem de ideias sobre DNS que parecem razoáveis, mas não são precisas. Esclarecer essas ideias facilita a resposta calma quando as coisas não são atualizadas instantaneamente.
“As alterações no DNS são instantâneas.”
As atualizações de DNS não se propagam para a internet em tempo real. Elas são captadas conforme os caches expiram e os resolvedores atualizam seus dados. Mesmo uma alteração perfeitamente configurada é implementada gradualmente.
“Se o site estiver fora do ar, o DNS está com problema.”
A maior parte do tempo de inatividade durante a migração não é causada pelo DNS. Erros de SSL, configurações incorretas do servidor ou problemas de aplicativos muitas vezes parecem falhas de DNS porque os usuários não conseguem carregar o site.
“Limpar o cache resolve a propagação.”
Limpar o cache do navegador pode ajudar um único usuário a ver o novo site, mas não altera o que os resolvedores ou ISPs têm armazenado em cache. A propagação ocorre nos prazos deles, não nos teus.
“É preciso alterar os servidores de nomes em toda migração.”
As alterações nos servidores de nomes só são necessárias ao trocar de provedor de DNS. A maioria das migrações de sites funciona perfeitamente bem sem mexer nos servidores de nomes.
Se você precisar fazer alterações, pode acessar os servidores de nomes da Kinsta no MyKinsta em DNS > Alterar servidores de nomes no seu registrador.
O DNS raramente se comporta de forma imprevisível porque está com defeito. Ele se comporta de forma previsível de acordo com regras que são fáceis de entender mal. Conhecer essas regras elimina grande parte do pânico que cerca as migrações.
Lista de verificação pós-migração: o que fazer depois que o DNS estiver ativo
Depois que as alterações de DNS estão em vigor, o trabalho não terminou. O objetivo agora é confirmar que o tráfego está chegando consistentemente ao novo ambiente e que nada está falhando silenciosamente em segundo plano.
- Comece confirmando que o tráfego está chegando ao novo servidor: verifique os registros do servidor, as análises ou os painéis de controle de hospedagem para confirmar que as solicitações estão chegando ao IP e ao ambiente corretos. Tráfego misto é normal no início, mas deve caminhar totalmente para o novo site.
- Verifique SSL e redirecionamentos: certifique-se de que os certificados são válidos para todos os domínios esperados e que os redirecionamentos de HTTP para HTTPS e os redirecionamentos legados se comportam conforme o esperado. Erros de certificado ou loops de redirecionamento frequentemente aparecem somente depois que o tráfego real chega.
- Monitore registros e taxas de erro: fique atento a picos de erros 404, erros 500 ou solicitações bloqueadas. Esses sinais frequentemente revelam problemas de configuração esquecidos que não eram visíveis durante os testes.
- Depois que o tráfego se estabilizar, restaure os valores normais de TTL: TTLs mais longos reduzem o volume de consultas DNS e melhoram a eficiência dos resolvedores. Essa etapa é frequentemente esquecida, mas é importante para a estabilidade a longo prazo.
- Remova os ambientes legados com segurança: não desligue o servidor antigo até ter certeza de que ele não está mais recebendo tráfego relevante. Uma breve janela de sobreposição evita que falhas em casos extremos se tornem interrupções.
Essa revisão final transforma uma atualização de DNS bem-sucedida em uma migração limpa e estável.
O tempo de inatividade durante a migração geralmente é opcional
O tempo de inatividade durante uma migração de site geralmente é resultado de alterações apressadas, responsabilidades sobrepostas ou de tratar o DNS como algo que precisa ser “consertado” sob pressão.
As migrações mais seguras priorizam a preparação em vez da velocidade. Hospedagem, configuração de aplicação e SSL são validados primeiro. O DNS é atualizado por último, com expectativas realistas sobre propagação e cache.
Com o fluxo de trabalho e o suporte certos, as migrações de sites não precisam ser estressantes ou arriscadas. E quando as alterações de DNS ocorrem em um ambiente estável e gerenciado, como os serviços de hospedagem gerenciada oferecidos pela Kinsta, o tempo de inatividade se torna coisa do passado.
