Entender o DNS e Por Que Importa Migração Segura

O Sistema de Nomes de Domínio (DNS) é a agenda da internet. Quando alguém digita seu domínio em um navegador, o DNS traduz esse nome legível para o endereço IP onde seu site, e-mail ou outros serviços estão hospedados. Migrar seus registros de DNS de um provedor para outro – ou atualizá-los dentro do mesmo provedor – altera como o mundo atinge seus ativos digitais. Um único registro mal configurado pode fazer com que seu site vá offline, e-mail para rebote ou protocolos de segurança falhe.

Migração segura significa zero ou quase zero paradas, sem perda de serviço e sem exposição não intencional a vulnerabilidades. Este guia expandido o acompanha em todas as fases, desde a descoberta inicial até a validação final, para que você possa migrar com confiança. Vamos cobrir tipos de registros, otimização de TTL, estratégias de backup, mudanças de nome do servidor, monitoramento de propagação e armadilhas comuns – tudo em passos claros e acionáveis.

Recursos externos como Centro de aprendizagem DNS da Cloudflare e O DNS da ICANN fornece contexto fundacional, mas este guia foca-se nas etapas operacionais que você precisa executar.

Preparação Antes da Migração

Preparação adequada é o fator mais importante em uma migração segura de DNS. Correr para mudanças sem um inventário completo de seus registros é uma receita para o desastre. Comece por auditoria do seu ambiente atual de DNS a partir do painel de controle ou API do provedor existente.

Inventário Todos os tipos de registro DNS ativos

Crie uma lista detalhada de todos os registros em sua zona. Isso inclui não só os registros óbvios A e CNAME, mas também tipos menos usados como SRV, NS, PTR (rara para hospedagem de nível de domínio) e CAA. Para a maioria dos domínios, você provavelmente encontrará:

  • A records – map hostnames to IPv4 address
  • registosAAAA – nomes das máquinas de mapas para endereços IPv6
  • CNAME records – alias de um nome para outro (por exemplo, www to root domain)
  • MX records – tráfego direto de e-mail para servidores de e-mail
  • TXT records – carregar texto legível por máquina, comumente usado para fichas de verificação SPF, DKIM, DMARC e domínio
  • NS records – especifique servidores de nomes autorizados para subdomínios (menos comuns a alterações)
  • Records SRV – definem serviços como SIP, LDAP ou CalDAV
  • Registros CAA – permitem que as autoridades de certificação emitem certificados SSL para o domínio

Exportar o arquivo da zona se o seu provedor o suporta. A maioria dos painéis de controle tem uma opção “Zona de Exportação” ou “Baixar Arquivo da Zona”. Caso contrário, copie manualmente cada registro em uma planilha, anotando o nome, tipo, valor, TTL e prioridade (para MX e SRV).

Entender os Valores Tempo-para-Viver (TTL)

O TTL determina o tempo que os resolvedores de DNS armazenam os seus registos. Um TTL elevado (por exemplo, 86400 segundos = 24 horas) significa que as alterações se propagam lentamente. Um TTL baixo (por exemplo, 300 segundos = 5 minutos) permite atualizações rápidas mas aumenta a carga de consultas. Antes da migração, você deve diminuir os TTLs em todos os registros críticos para um valor como 300 ou 600 segundos, pelo menos 48 horas antes de fazer quaisquer alterações. Isto garante que, quando você atualiza os registros, os valores antigos de cache expiram rapidamente, reduzindo a chance de que alguns usuários vejam as informações antigas enquanto outros vejam as novas.

Nota: Alguns provedores permitem que as alterações de TTL apenas através de sua interface; planejar de acordo. Para registros relacionados ao e-mail (MX, SPF, DKIM), baixos TTLs são especialmente importantes porque os problemas de entrega de e-mail podem ser difíceis de diagnosticar.

Identificar as Dependências e os Interessados

Os seus registos DNS não existem num vácuo. Eles ligam- se a alojamento na Web, serviços de e- mail, APIs de terceiros, CDNs, balanceadores de carga e sistemas de autenticação.

  • Mapear todos os serviços que dependem de um registro DNS. Por exemplo, um subdomínio api.example.com pode ser usado pelo seu aplicativo móvel.
  • Informe sua equipe, clientes ou stakeholders relevantes sobre a janela de mudança planejada. Mesmo com planejamento cuidadoso, breves atrasos de propagação podem causar problemas intermitentes.
  • Certifique-se de ter acesso administrativo tanto ao provedor DNS antigo quanto ao novo provedor, bem como ao seu registrador de domínio (onde os servidores de nomes estão definidos).

Teste o seu processo de backup e restauração

Pratique literalmente restaurar a partir do seu backup em um ambiente de não-produção, se possível. Alguns provedores oferecem uma “sandbox” ou zona secundária. Verifique se você pode importar o arquivo de zona para o novo provedor sem erros de sintaxe. Ferramentas como DNS Scanner[ ou ZoneCut[[ podem validar a sintaxe de arquivo de zona antes de você se comprometer.

Processo de migração passo a passo

Uma vez que sua preparação esteja completa e seus TTLs estejam baixos (esperar tempo suficiente para que o TTL baixo se propague globalmente), siga estes passos metodicamente.

1. Backup existente DNS Records (Exportação Formal)

Crie uma cópia de segurança que você pode restaurar rapidamente se algo der errado. O melhor backup é o arquivo de zona exportada do seu provedor antigo. Se isso não for possível, copie todos os registros em um formato estruturado (CSV, JSON ou até mesmo um arquivo de texto). Inclua os seguintes campos para cada registro:

  • Nome (por exemplo, @, www, correio)
  • Tipo (A, AAAA, CNAME, MX, TXT, etc.)
  • Valor / Alvo
  • TTL
  • Prioridade (para MX, SRV)
  • Outros metadados (peso, porto para SRV)

Armazene este backup em um local seguro, como um gerenciador de senhas, armazenamento em nuvem criptografado ou uma unidade offline. Não confie apenas na interface do provedor antigo – se sua conta for encerrada ou o acesso for perdido, você precisa de uma cópia portátil.

2. Configure os registros DNS no novo provedor

Entre no painel do seu novo provedor de DNS e crie cada registro exatamente como ele apareceu em seu backup.

  • Use as mesmas configurações de TTL (idealmente os valores baixos que você definiu anteriormente).
  • Para registros MX, certifique-se de que os números de prioridade correspondem exatamente. Os registros MX são processados em ordem de prioridade mais baixa primeiro.
  • Para registros TXT contendo SPF ou DKIM, copie todo o texto, incluindo as marcas de aspas potenciais. Alguns provedores embrulham valores TXT longos; assegure que o valor completo é introduzido.
  • Para registros CNAME, lembre-se que o domínio root (@) geralmente não pode ser um CNAME (por RFC). Em vez disso, use um registro A ou AAAA ou um ALIAS/ANAME se o novo provedor o suportar.
  • Verifique novamente quaisquer registros prefixados com sublinhado (comum para DKIM, DMARC ou descoberta de serviço) – eles são sensíveis a casos e devem ser exatos.

Depois de inserir todos os registros, faça uma comparação visual com o backup. Você também pode usar uma ferramenta de busca de DNS de terceiros para consultar diretamente os servidores de nomes do novo provedor (se eles oferecem tal recurso) para verificar se os registros estão ao vivo em sua infraestrutura. Muitos provedores têm uma opção "Preview" ou "Test" que mostra como os registros irão resolver.

3. Atualizar servidores de nomes em seu secretário

Este é o ponto crítico onde a internet começa a aprender sobre o seu novo provedor de DNS. Entre no seu registro de domínio (a empresa a quem você comprou o domínio, por exemplo, GoDaddy, Namecheap, Google Domains) e localize as configurações do servidor de nomes. Substitua os servidores de nomes existentes com os fornecidos pelo seu novo provedor de DNS. Normalmente, você terá dois ou quatro nomes de host como e .

[[ FLT: 0]] Importante: [[ FLT: 1]] Não remova ainda os servidores antigos. Em vez disso, adicione os novos ao lado dos antigos se o registrador permitir (algumas fazem, algumas forçam uma troca direta). A abordagem mais segura é adicionar primeiro novos servidores de nomes, aguarde a propagação, e depois remova os antigos. Contudo, muitos registradores exigem que você os substitua completamente. Nesse caso, prossiga com a troca, mas mantenha a zona de DNS ativa por pelo menos 48 horas. Isto lhe dará um retorno se precisar de reverter os servidores de nomes rapidamente.

Depois de salvar as alterações, note a hora exata. A propaganda começa a partir deste momento.

4. Verifique a delegação do servidor de nomes

Use uma ferramenta como DNS Checker ou para confirmar que os novos servidores de nomes são autoritários. Verifique se o registro SOA (Início da Autoridade) reflete seu novo provedor. Se você ver resultados mistos (algumas pessoas resolvendo servidores de nomes antigos, alguns novos), isso é normal durante a propagação. Espere algumas horas e verifique novamente.

Monitoramento e validação durante a propagação

A propagação do DNS não é instantânea. Mesmo com TTLs baixos, o cache em vários níveis (solucionadores de ISP, sistemas operacionais, navegadores) pode atrasar as atualizações. Planeje uma janela de propagação de até 48 horas, embora a maioria das consultas de DNS reflita a mudança na primeira hora se os TTLs forem baixos.

Usar várias Damas Globais

Monitore a transição usando ferramentas que consultam de várias localizações geográficas. Serviços como whatsmydns.net ou DNS-Check.online mostram se cada registro se propagou para locais ao redor do mundo. Foque-se em registros críticos:

  • A/AAAA – o seu site deve resolver com o IP correto.
  • MX – os servidores de e-mail devem ser os pretendidos.
  • TXT records (SPF, DKIM, DMARC) – a autenticação por email deve permanecer intacta.

Teste o e-mail e os serviços Web continuamente

Não confie apenas em damas DNS. Na verdade, teste os serviços:

  • Abra o seu site em um navegador de diferentes redes (por exemplo, dados móveis vs. Wi-Fi doméstico).
  • Envie e-mails de teste para e do seu domínio usando vários clientes de e-mail.
  • Verifique quaisquer endpoints ou subdomínios da API que sejam críticos para os negócios.
  • Se você usar certificados SSL, certifique-se de que eles validem corretamente (os registros CAA podem estar envolvidos).

Mantenha a Zona Velha Ativa como uma Rede de Segurança

Como mencionado, mantenha a zona ativa e inalterada do seu antigo provedor de DNS por pelo menos um ciclo de propagação completo (normalmente 48 horas). Se você descobrir um erro crítico – como um registro faltando que quebra o e-mail – você pode reverter a mudança de servidor de nomes no seu registrador, e o mundo voltará para os registros antigos e operacionais dentro do período TTL. Sem esse backup, um rollback torna-se muito mais difícil porque a zona antiga pode não estar mais ao vivo.

Pós-migração: Passos finais e limpeza

Uma vez que você tenha confirmado que todos os serviços estão funcionando corretamente e a propagação está completa (a maioria das damas globais mostram 100% de consistência), você pode finalizar a migração.

Remover os Registos de DNS e os Servidores de Nomes Antigos

  • Excluir a zona DNS antiga do painel do seu provedor anterior para evitar confusão.
  • Se você tiver adicionado servidores de nomes antigos e novos no registrador, remova os antigos agora. Alguns registradores permitem que você deixe servidores de nomes extras; é mais limpo para manter apenas os novos.
  • Atualizar TTLs para valores mais elevados para a estabilidade da produção. Por exemplo, configure registros A/AAAA para 3600 (1 hora) ou 86400 (1 dia) se você raramente alterar IPs. Mantenha registros MX e TXT moderados (3600-14400).

Validar os Registos de Segurança

Segurança de e-mail muitas vezes depende de SPF, DKIM e DMARC. Use um validador como DMARC Analyzer para garantir que seus registros TXT estão corretamente configurados. Verifique se seus registros de seletor DKIM estão presentes e correspondentes ao que seu provedor de email espera. Um SPF mal configurado pode fazer com que os e-mails legítimos sejam repelidos ou marcados como spam.

Documentar a Migração

Crie um registro do que foi feito exatamente, quando e quaisquer problemas encontrados. Esta documentação se torna inestimável para futuras migrações, auditorias ou quando treinar novos membros da equipe.

Dicas avançadas e armadilhas comuns

Tempo TTL baixo

Defina TTLs para um valor baixo pelo menos o mesmo número de segundos antes da alteração do TTL original. Se o seu TTL antigo foi 86400 (24 horas), reduza-o 24 horas antes de planear trocar servidores de nomes. Caso contrário, alguns solucionadores poderão guardar os registos antigos para o dia inteiro após a alteração, causando um mundo dividido.

Tempo de parada de e- mail durante a migração de registro MX

O e- mail é o serviço mais sensível durante uma migração de DNS. Se alterar os registos MX e o novo servidor de e- mail esperar diferentes credenciais ou configurações, poderá perder os e- mails. Considere estas etapas:

  • Execute servidores de e-mail antigos e novos simultaneamente durante a transição, se possível (registros MX duplos com prioridades diferentes).
  • Defina um TTL muito baixo (300 segundos) nos registros MX por alguns dias antes da mudança.
  • Teste o envio e recebimento através de ambos os servidores antes do cutover.

Evite colisões CNAME

Um registro CNAME não pode coexistir com qualquer outro registro do mesmo nome. Por exemplo, se você tiver um CNAME para , você também não pode ter um registro TXT ou MX para . Certifique-se de que seu design DNS respeita esta regra no novo provedor.

Utilização do DNSSEC

Se o seu domínio usar o DNSSEC, você deve coordenar as chaves de assinatura entre os seus provedores antigos e novos. O DNSSEC adiciona uma camada de segurança, mas também complexidade. Desativar o DNSSEC antes da migração e voltar a ser o seu novo usuário, é muitas vezes mais seguro, mas o domínio será menos seguro durante a janela.

Serviços de terceiros com IPs estáticos

Se o seu site ou aplicativo usa um serviço de terceiros que lista de IPs (por exemplo, gateways de pagamento, provedores de APIs), atualize essas listas de IP se o seu novo provedor de hospedagem usar IPs diferentes. Caso contrário, chamadas de serviço podem ser bloqueadas após a mudança de DNS.

Conclusão

Migrar registros DNS não é inerentemente arriscado se você se preparar e executar metodicamente. Baixo TTLs, backups completos, validação multi-passos e uma rede de segurança de servidores antigos reduzem drasticamente a chance de um tempo de inatividade estendido. Seguindo os passos e dicas expandidas neste guia, você pode mover o DNS do seu domínio para um novo provedor – ou atualizar registros existentes – com o mínimo de interrupção para o seu site, e-mail e outros serviços críticos. Lembre-se que o DNS é a base da sua presença online; trate-o com o cuidado que merece.