DNS e domínio: como publicar um site sem interromper serviços

DNS não muda em todos os lugares ao mesmo tempo. Uma publicação segura mantém os ambientes antigo e novo compatíveis durante a janela de cache.

Runbook de publicação: a mudança começa antes do novo servidor Um domínio pode atender vários serviços ao mesmo tempo: Alterar “o DNS” sem inventário pode interromper mais do que a página principal. Este runbook utiliza uma migração hipotética: Os endereços pertencem a blocos reservados para documentação. Substitua os pelos valores reais somente depois de revisar o procedimento. T 7 dias: descubra quem controla o quê Identifique: registrador; titular do domínio; servidores autoritativos; painel DNS; responsável; MFA; data de renovação; contatos de recuperação; DNSSEC; fornecedor de e mail; CDN; certificados; subdomínios. Consultas iniciais: O comando dig precisa estar instalado. Em Debian e Ubuntu, costuma ser fornecido pelo pacote dnsutils . Não altere nada nesta etapa. Servidor autoritativo e resolver não são a mesma coisa O servidor autoritativo publica a informação oficial da zona. O resolver consulta servidores DNS, guarda respostas em cache e atende clientes. A RFC 1034 descreve o DNS como um sistema distribuído que utiliza cache para melhorar desempenho. Atualizações não aparecem em todos os resolvers ao mesmo tempo. T 7 dias: exporte a zona Registre todos os itens: Nome Tipo Valor TTL Finalidade Owner : @ A IP antigo 3600 site Web www CNAME domínio principal 3600 site Web @ MX servidor de e mail 3600 e mail TI @ TXT SPF 3600 autenticação E mail selector. domainkey TXT DKIM 3600 autenticação E mail dmarc TXT DMARC 3600 política E mail Faça exportação pelo provedor quando disponível e mantenha uma cópia controlada. Screenshots ajudam, mas não substituem arquivo estruturado. T 6 dias: determine o tipo de mudança Troca apenas do site Normalmente exige alterar: A; AAAA; CNAME relacionado ao site; eventualmente registros de validação. Não exige trocar: MX; SPF; DKIM; DMARC; subdomínios independentes. Troca de provedor DNS Altera a delegação de nameservers e pode afetar toda a zona. É mais sensível porque o novo provedor precisa possuir todos os registros antes da mudança. Transferência do domínio Muda o registrador. Não deveria exigir troca de hospedagem ou DNS, mas precisa ser planejada conforme regras e prazos da extensão. Ativação de CDN Pode mudar A, AAAA ou CNAME e acrescentar comportamento de proxy e cache. Não combine alterações independentes na mesma janela sem necessidade. T 5 dias: prepare o destino O novo ambiente precisa funcionar antes do DNS. Valide: aplicação; banco; uploads; redirects; proxy; firewall; logs; monitoramento; backup; healthcheck; e mail transacional; jobs; capacidade. Para testar o novo IP mantendo o domínio no cabeçalho e no TLS: Para www : O comando ignora DNS apenas para essa chamada. Ele não altera a zona. Verifique: status; certificado; conteúdo; redirects; headers; cookies; formulários. T 4 dias: prepare HTTPS O novo servidor precisa apresentar certificado válido para os nomes atendidos. O Let’s Encrypt permite validar controle do domínio por: recurso HTTP; registro DNS. A validação HTTP pode depender de o tráfego já alcançar o novo ambiente. A validação DNS pode permitir emissão antes da troca, conforme cliente e provedor. Não copie chave privada de forma improvisada entre servidores. Use emissão nova ou transferência segura quando tecnicamente justificada. Valide renovação automática depois da publicação. T 48 horas: reduza o TTL TTL significa Time to Live . Ele indica por quanto tempo uma resposta pode permanecer em cache. Se o registro atual possui TTL de 3600 segundos, reduzi lo para 300 não elimina cópias que já foram armazenadas com 3600. Por isso: 1. reduza o TTL; 2. espere pelo menos o TTL anterior; 3. somente depois realize a troca. Exemplo: Na prática, faça a redução com antecedência adicional. A documentação de TTL mostra que valores e mínimos disponíveis variam conforme o provedor e o modo do registro. TTL baixo aumenta consultas e não deve permanecer reduzido indefinidamente sem motivo. T 24 horas: confirme que os dois ambientes podem coexistir Durante a transição, pessoas diferentes podem acessar destinos diferentes. Os dois precisam permanecer funcionais. Isso é especialmente importante quando há: login; sessão; uploads; formulário; banco; carrinho; jobs; processamento assíncrono. Site estático Coexistência costuma ser simples se ambos servem os mesmos arquivos. Aplicação com banco compartilhado Verifique compatibilidade de schema e versão. Aplicação com bancos separados Dados podem divergir. É necessário: modo somente leitura; sincronização; janela curta; roteamento controlado; migração final; estratégia específica. DNS não coordena transações. Ele apenas influencia resolução de nomes. T 12 horas: defina o plano de retorno Registre: Retornar o registro não move instantaneamente todos os usuários de volta. Alguns resolvers já terão armazenado o destino novo. Por isso, o servidor novo não deve ser desligado imediatamente depois do rollback. T 1 hora: congele mudanças relacionadas Evite durante a janela: deploy não relacionado; atualização de banco; troca de e mail; alteração de firewall; mudança de CDN; rotação de credenciais; atualização de CMS. Quanto menos variáveis, mais fácil diagnosticar. Registre o estado: T0: altere somente o necessário Exemplo: Preserve registros que não participam da mudança. Não apague o A antigo antes de confirmar que possui seu valor para retorno. T+2 minutos: consulte o autoritativo Descubra os nameservers: Consulte um deles diretamente: O autoritativo deve responder com o novo valor. Se não responder: alteração pode não ter sido salva; zona errada pode ter sido editada; nameserver consultado pode não ser o ativo; sincronização interna do provedor pode estar pendente. T+5 minutos: consulte resolvers públicos Isso oferece amostras. Não prova que todos os resolvers foram atualizados. A expressão “propagação concluída” simplifica um processo distribuído. Cada cache expira conforme a resposta que recebeu. T+10 minutos: valide o serviço, não apenas o IP Execute também tarefas reais controladas: abrir página; fazer login; enviar formulário de teste; consultar API; carregar arquivo; verificar e mail; observar logs; confirmar certificado. Um DNS correto pode apontar para uma aplicação quebrada. T+15 minutos: confirme o e mail Verifique que os registros permaneceram: O site e o e mail compartilham o domínio, mas podem usar infraestruturas diferentes. Trocar o registro A do domínio principal pode afetar e mail quando alguma configuração depende desse mesmo host. O inventário precisa revelar essa relação. T+30 minutos: compare os dois destinos Use chamadas diretas: Verifique: resposta; versão; banco; filas; erros; dados. Não use apenas a página inicial armazenada no navegador. T+1 hora: decida entre continuar ou voltar Continue quando: autoritativos respondem corretamente; serviço novo está saudável; fluxos críticos funcionam; erros permanecem dentro do limite; certificados são válidos; dados estão consistentes; e mail continua operando. Faça rollback quando: impacto é relevante; causa não é conhecida; correção excede a janela; dados podem divergir; segurança está comprometida. O plano de rollback precisa considerar que restaurar DNS não desfaz alterações de aplicação ou banco. T+TTL: ainda não desligue o servidor antigo Espere: múltiplos TTLs; encerramento de conexões; processamento de jobs; migração de uploads; confirmação de logs; ausência de tráfego significativo. Observe acessos no servidor anterior. Resolver, navegador, sistema operacional e aplicações podem possuir caches adicionais. T+24 horas: restaure um TTL operacional Exemplo: O valor correto depende de: frequência de mudanças; necessidade de failover; custo de consultas; comportamento do provedor; criticidade. Não mantenha TTL baixo apenas porque uma migração ocorreu. Troca de nameservers exige outro nível de cuidado Antes de alterar a delegação: 1. crie a zona completa no novo provedor; 2. valide registros; 3. compare respostas; 4. preserve e mail; 5. verifique DNSSEC; 6. confirme glue records quando aplicável; 7. altere a delegação; 8. mantenha o provedor antigo ativo durante a transição. Se DNSSEC estiver habilitado, uma mudança incorreta de chaves ou registro DS pode tornar o domínio inválido para resolvers que validam assinaturas. Não desative DNSSEC por reflexo. Planeje a migração com o procedimento do registrador e do provedor DNS. CNAME não é redirecionamento HTTP Um CNAME cria um alias DNS. Ele não envia o navegador de: para: Um redirect 301 ou 308 é resposta HTTP produzida pelo servidor, proxy ou CDN. Confundir as duas camadas gera configurações difíceis de diagnosticar. A documentação de tipos de registros ajuda a diferenciar A, AAAA, CNAME, MX, TXT e outros tipos. CDN e proxy alteram o que o DNS revela Quando o domínio aponta para uma CDN, a consulta pode retornar endereços da rede intermediária, não do servidor de origem. Nesse cenário, valide: modo proxy; certificado na borda; certificado na origem; firewall; headers; cache; IP real; bypass da origem. O artigo sobre CDN e cache cobre a política de conteúdo depois que o tráfego chega à borda. Checklist final Antes [ ] Controle do domínio confirmado. [ ] Zona exportada. [ ] Registros classificados. [ ] Novo ambiente validado. [ ] HTTPS pronto. [ ] TTL reduzido com antecedência. [ ] Servidores coexistem. [ ] Backup e rollback definidos. Durante [ ] Somente registros necessários alterados. [ ] Autoritativos consultados. [ ] Resolvers públicos consultados. [ ] Fluxos críticos testados. [ ] E mail preservado. [ ] Logs e métricas acompanhados. Depois [ ] Servidor antigo mantido durante a janela. [ ] Tráfego residual verificado. [ ] TTL restaurado. [ ] Documentação atualizada. [ ] Acessos antigos removidos. [ ] Certificado e renovação confirmados. DNS não é um botão global de troca. Uma publicação segura assume que informações antigas continuarão circulando temporariamente e mantém os dois lados preparados para esse período.