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.
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.
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.
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.
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 |
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.
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.
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.
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.
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.
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.