# Um manual de transição de domínio, DNS e TLS para um novo servidor | SwissOctet Insights https://swissoctet.com/pt/insights/dns-tls-cutover-runbook/ SwissOctet / Informações / Web e onion Web e onion Aplicado · 4 min de leitura Um manual de transição de domínio, DNS e TLS para um novo servidor Prepare o encaminhamento de nomes de anfitrião, certificados e reversão em conjunto, para que uma migração mude o servidor sem quebrar a identidade do site nem as ligações seguras. Por SwissOctet Editorial Guardar guia Copiar ligação NESTA PÁGINA 01 Inventarie os nomes e as dependências 02 Prepare o encaminhamento de nomes de anfitrião no novo servidor 03 Escolha um método de validação de certificados 04 Planeie a janela de cache antes de alterar DNS 05 Verifique DNS e TLS separadamente 06 Faça da reversão também uma decisão de dados 07 Observe o site após a mudança A sua lista de verificação prática Fontes e leitura adicional Voltar à biblioteca A RESPOSTA DIRETA Prepare o servidor e o certificado para o nome de anfitrião pretendido, teste a aplicação antes de alterar o DNS público e mantenha o ambiente antigo disponível durante a transição. Verifique registos autoritativos, respostas em cache e TLS independentemente. Uma atualização de DNS por si só não estabelece que estão a ser servidos a aplicação e o certificado corretos. 01 Inventarie os nomes e as dependências Liste todos os nomes de anfitrião que o site utiliza, incluindo o domínio principal, aliases, endpoints de API e callbacks da aplicação. Registe quem controla o registo e o DNS autoritativo. Alojar uma aplicação não regista automaticamente o seu domínio nem dá ao operador do servidor o controlo dos seus registos. Mantenha o acesso ao ambiente existente até o novo ter sido validado. Identifique também registos de email e de verificação de terceiros que a mudança deve preservar. Uma migração de site não deve substituir casualmente uma zona DNS inteira. Faça um plano de alteração ao nível dos registos com os endereços pretendidos e um valor de reversão. Guarde as credenciais em privado; o manual de operações precisa de responsáveis e procedimentos, não de palavras-passe reais nem de tokens API. 02 Prepare o encaminhamento de nomes de anfitrião no novo servidor Uma máquina que recebe uma ligação tem de servir a aplicação pretendida para o seu nome de anfitrião. Configure o servidor web ou o painel de alojamento em conformidade, com a raiz pública de documentos separada da configuração privada e das credenciais. Teste todos os nomes e redirecionamentos necessários, não apenas uma página de boas-vindas genérica acedida através do endereço do servidor. Use um método de teste controlado que envie o nome de anfitrião pretendido para o novo endpoint antes da alteração pública. Verifique início de sessão, carregamentos e ligações geradas pela aplicação, quando aplicável. Desative tarefas que possam duplicar ações de produção durante os testes. O teste deve provar o comportamento da aplicação sem enviar correio real, efetuar pagamentos ou modificar involuntariamente a base de dados ativa antiga. 03 Escolha um método de validação de certificados A emissão de certificados exige prova de controlo dos nomes pedidos. A Let's Encrypt documenta HTTP-01 e DNS-01 entre os seus métodos de validação. A validação HTTP depende de servir corretamente o desafio exigido; a validação DNS usa um registo DNS especificado e pode suportar a emissão de wildcard. Selecione um método que se adeque à implementação real e possa ser mantido em segurança. Mantenha as credenciais de validação com o âmbito mais restrito possível. A automatização de DNS é especialmente sensível porque credenciais DNS amplas podem afetar mais do que um site. Planeie a renovação do certificado e como os ficheiros renovados chegam ao processo que os serve. Uma primeira emissão bem-sucedida é útil, mas um site também precisa de um processo de renovação funcional e de monitorização do certificado que realmente apresenta. 04 Planeie a janela de cache antes de alterar DNS Os registos DNS têm um time-to-live usado pelos resolvers ao colocar respostas em cache. Uma alteração de registo não substitui instantaneamente todos os resultados em cache. Se uma transição beneficiar de um TTL mais curto, planeie o ajuste com antecedência suficiente para que as respostas previamente em cache possam expirar. Mantenha os ambientes antigo e novo capazes de lidar com a transição que concebeu. Esta sequência ilustrativa separa a preparação da transição pública. O seu timing tem de ser adaptado ao domínio, ao comportamento dos resolvers e à aplicação. Não é um calendário universal de propagação. Uma migração com escritas ativas também exige uma transição de dados específica da aplicação, porque, caso contrário, dois servidores web funcionais podem aceitar alterações em conjuntos de dados diferentes. Fase Ação Condição antes de prosseguir Preparação Inventarie registos e configure o novo endpoint A aplicação funciona para os nomes pretendidos Certificado Emita e instale o certificado Cadeia correta e nome de anfitrião validam Transição Atualize apenas os registos DNS planeados A transição de dados e a reversão estão definidas Observação Verifique resultados autoritativos e de clientes Os percursos do utilizador têm sucesso através do novo endpoint Conclusão Retire o serviço antigo após validação Tráfego residual e necessidades de recuperação revistos 05 Verifique DNS e TLS separadamente Verifique primeiro o registo autoritativo e depois compare respostas de clientes ou resolvers envolvidos na transição. Um valor autoritativo correto e um valor em cache mais antigo podem coexistir. Inspecione o endpoint alcançado pelo navegador em vez de assumir que todas as ligações já usam o novo endereço. Mantenha as observações com data e hora para que a transição seja compreensível. Para TLS, valide o nome de anfitrião pretendido, a validade do certificado e a cadeia através de uma ligação real de cliente. Inspecione todos os aliases e caminhos de redirecionamento necessários. A documentação TLS da Mozilla explica a autenticação do servidor e as preocupações com conteúdo misto: a página e os seus sub-recursos devem ser entregues em segurança. Um certificado num nome de anfitrião não cobre automaticamente outro endpoint da aplicação. 06 Faça da reversão também uma decisão de dados Uma reversão de DNS pode redirecionar o tráfego, mas não reverte as escritas feitas na nova aplicação. Defina como irá tratar esses dados antes da transição. Para uma publicação estática, a reversão pode ser simples; para um serviço que aceita carregamentos ou encomendas, o estado da aplicação precisa de um responsável claro e de um procedimento de reconciliação. Imagine migrar um pequeno site de publicação com comentários. Pode preparar um intervalo de manutenção ou uma transição controlada só de leitura enquanto os dados finais são copiados. Teste o procedimento de reabertura e mantenha a implementação antiga pronta. Escolha a abordagem que se adequa à aplicação em vez de usar uma alteração de DNS como substituto do planeamento de consistência. 07 Observe o site após a mudança Verifique percursos reais de utilizador, taxas de erro, apresentação de certificados e tarefas em segundo plano depois de o novo endpoint receber tráfego. Confirme que as cópias de segurança agora abrangem a aplicação e os dados pretendidos. Reveja o acesso ao servidor antigo antes da retirada e remova credenciais obsoletas quando as necessidades de recuperação e reversão tiverem sido resolvidas. Registe a configuração final de DNS e do certificado. Ao selecionar alojamento web ou computação SwissOctet, confirme as responsabilidades reais de domínio, certificado e administração para a configuração. O catálogo fornece um destino de alojamento e recursos; não estabelece que o seu domínio já foi ligado nem que a renovação do certificado foi configurada. Mantenha esses passos concretos e verificáveis no plano de implementação. TRANSFORME ISTO EM AÇÃO A sua lista de verificação prática. ✓ Inventarie todos os nomes de anfitrião e preserve registos DNS não relacionados. ✓ Teste o encaminhamento de nomes de anfitrião antes da transição pública. ✓ Escolha e automatize um desafio de certificado adequado. ✓ Planeie alterações de TTL e a transição de dados. ✓ Verifique DNS e TLS através de verificações separadas. ✓ Mantenha o acesso de reversão e resolva as novas escritas antes de reverter. Descarregar lista de verificação PERGUNTAS FREQUENTES Os detalhes que importam. Alterar um registo A ativa HTTPS? + Não. DNS escolhe um endpoint; esse endpoint ainda precisa do encaminhamento de nome de anfitrião correto e de um certificado válido e instalado. Posso reverter apenas o registo DNS se algo falhar? + O tráfego pode ser redirecionado, mas as escritas da aplicação exigem tratamento separado. Defina um plano de reversão ou reconciliação de dados antes da migração. Um certificado wildcard é sempre necessário? + Não. Escolha os nomes do certificado e a validação de acordo com os nomes de anfitrião reais. Um wildcard tem requisitos específicos de cobertura e validação; não é um atalho universal de migração. REFERÊNCIAS PRIMÁRIAS Vá à fonte. Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção. Let's Encrypt: Tipos de desafio letsencrypt.org IETF RFC 1034: Conceitos e instalações de DNS datatracker.ietf.org Mozilla MDN: Transport Layer Security developer.mozilla.org Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente. LIGUE O CONHECIMENTO Infraestrutura relacionada. Canvas Web Suíça Vector VPS Suíça Pulse NVMe Suíça MANTENHA O FIO As suas próximas notas de campo. Explore todos os guias NOTA DE CAMPO / 01 + Cloud e VPS Fundação Como escolher um VPS sem adivinhar Transforme uma ideia de aplicação num orçamento de recursos útil e compare depois CPU, memória, armazenamento e transferência em conjunto. 4 min de leitura Leia o guia NOTA DE CAMPO / 02 + Web e onion Fundação Alojamento web ou um VPS: escolha o trabalho que quer assumir Compare os requisitos da aplicação, o controlo e as responsabilidades de manutenção, em vez de tratar um VPS como o passo seguinte automático para todos os sites. 6 min de leitura Leia o guia NOTA DE CAMPO / 03 + Web e onion Aplicado Publicar um serviço onion sem descurar a aplicação Planeie uma publicação onion legítima com exposição controlada do backend, revisão cuidadosa de conteúdo, recuperação de chaves de serviço e um modelo explícito de acesso do público. 4 min de leitura Leia o guia