Prepara il server e il certificato per l'hostname previsto, testa l'applicazione prima di modificare il DNS pubblico e mantieni disponibile il vecchio ambiente durante la transizione. Verifica separatamente record autorevoli, risposte in cache e TLS. Un aggiornamento di DNS da solo non stabilisce che l'applicazione e il certificato corretti siano serviti.
Inventaria i nomi e le dipendenze
Elenca ogni hostname usato dal sito, incluso il dominio principale, gli alias, gli endpoint API e i callback dell'applicazione. Registra chi controlla la registrazione e il DNS autorevole. Ospitare un'applicazione non registra automaticamente il suo dominio né dà all'operatore del server il controllo dei suoi record. Mantieni l'accesso all'ambiente esistente finché il nuovo non è stato validato.
Identifica anche i record di email e di verifica di terze parti che lo spostamento dovrebbe preservare. Una migrazione di sito web non dovrebbe sostituire casualmente un'intera zona DNS. Crea un piano di modifiche a livello di record con gli indirizzi previsti e un valore di rollback. Conserva le credenziali privatamente; il runbook ha bisogno di responsabili e procedure, non di password reali o token API.
Prepara il routing per hostname sul nuovo server
Una macchina che riceve una connessione deve servire l'applicazione prevista per il suo hostname. Configura di conseguenza il web server o il pannello di hosting, con la document root pubblica separata dalla configurazione privata e dalle credenziali. Testa tutti i nomi e i redirect richiesti, non solo una pagina di benvenuto generica raggiunta tramite l'indirizzo del server.
Usa un metodo di test controllato che invii il nome host previsto al nuovo endpoint prima della modifica pubblica. Verifica login, caricamenti e link generati dall'applicazione ove applicabile. Disabilita i job che potrebbero duplicare azioni di produzione durante il test. Il test deve dimostrare il comportamento dell'applicazione senza inviare posta reale, effettuare pagamenti o modificare involontariamente il vecchio database live.
Scegli un metodo di validazione del certificato
L'emissione del certificato richiede la prova del controllo per i nomi richiesti. Let's Encrypt documenta HTTP-01 e DNS-01 tra i suoi metodi di convalida. La convalida HTTP dipende dalla corretta erogazione della sfida richiesta; la convalida DNS utilizza un record DNS specificato e può supportare l'emissione con wildcard. Seleziona un metodo adatto al deployment effettivo e che possa essere mantenuto in modo sicuro.
Mantieni le credenziali di convalida con ambito ristretto ove possibile. L'automazione DNS è particolarmente sensibile perché credenziali DNS ampie possono influire su più di un sito web. Pianifica il rinnovo del certificato e come i file rinnovati raggiungono il processo di erogazione. Una prima emissione riuscita è utile, ma un sito necessita anche di un processo di rinnovo funzionante e del monitoraggio del certificato che effettivamente presenta.
Pianifica la finestra della cache prima di modificare DNS
I record DNS hanno un time-to-live utilizzato dai resolver quando memorizzano le risposte nella cache. Una modifica del record non sostituisce istantaneamente ogni risultato in cache. Se una transizione trae vantaggio da un TTL più breve, pianifica la regolazione con sufficiente anticipo affinché le risposte precedentemente in cache possano scadere. Mantieni sia il vecchio che il nuovo ambiente in grado di gestire la transizione che hai progettato.
Questa sequenza illustrativa separa la preparazione dal cutover pubblico. I suoi tempi devono essere adattati al dominio, al comportamento dei resolver e all'applicazione. Non è un programma di propagazione universale. Una migrazione che comporta scritture live necessita anche di un cutover dei dati specifico per l'applicazione, perché altrimenti due server web funzionanti possono accettare modifiche in set di dati diversi.
| Fase | Azione | Condizione prima di procedere |
|---|---|---|
| Preparazione | Inventaria i record e configura il nuovo endpoint | L'applicazione funziona per i nomi previsti |
| Certificato | Emetti e installa il certificato | Catena corretta e nome host convalidati |
| Transizione | Aggiorna solo i record DNS pianificati | Cutover dei dati e rollback sono definiti |
| Osservazione | Controlla i risultati autorevoli e dei client | I percorsi utente riescono attraverso il nuovo endpoint |
| Completamento | Dismetti il vecchio servizio dopo la convalida | Traffico residuo e necessità di ripristino riesaminati |
Verifica DNS e TLS separatamente
Controlla prima il record autorevole, poi confronta le risposte dai client o dai resolver coinvolti nella transizione. Un valore autorevole corretto e un valore più vecchio in cache possono coesistere. Ispeziona l'endpoint raggiunto dal browser invece di presumere che ogni connessione utilizzi già il nuovo indirizzo. Mantieni le osservazioni con timestamp in modo che la transizione sia comprensibile.
Per TLS, convalida il nome host previsto, la validità del certificato e la catena attraverso una connessione client effettiva. Ispeziona ogni alias e percorso di reindirizzamento richiesto. La documentazione TLS di Mozilla spiega l'autenticazione del server e i problemi di contenuto misto: la pagina e le sue sottorisorse dovrebbero essere erogate in modo sicuro. Un certificato su un nome host non copre automaticamente un altro endpoint dell'applicazione.
Rendi anche il rollback una decisione sui dati
Un rollback DNS può reindirizzare il traffico, ma non annulla le scritture effettuate sulla nuova applicazione. Definisci come gestirai quei dati prima del cutover. Per una pubblicazione statica, il rollback può essere semplice; per un servizio che accetta caricamenti o ordini, lo stato dell'applicazione necessita di un proprietario chiaro e di una procedura di riconciliazione.
Immagina di migrare un piccolo sito editoriale con commenti. Puoi preparare un intervallo di manutenzione o una transizione controllata in sola lettura mentre i dati finali vengono copiati. Testa la procedura di riapertura e mantieni pronto il vecchio deployment. Scegli l'approccio adatto all'applicazione invece di usare una modifica DNS come sostituto della pianificazione della coerenza.
Osserva il sito dopo il passaggio
Verifica i percorsi utente reali, i tassi di errore, la presentazione del certificato e le attività in background dopo che il nuovo endpoint riceve traffico. Conferma che i backup ora coprano l'applicazione e i dati previsti. Esamina l'accesso al vecchio server prima della dismissione e rimuovi le credenziali obsolete quando le necessità di ripristino e rollback sono state risolte. Registra la configurazione finale di DNS e del certificato.
Quando selezioni un hosting web o compute SwissOctet, conferma le effettive responsabilità su dominio, certificato e amministrazione per la configurazione. Il catalogo fornisce una destinazione di hosting e risorse; non stabilisce che il tuo dominio sia già stato collegato o che il rinnovo del certificato sia stato configurato. Mantieni questi passaggi concreti e verificabili nel piano di deployment.
La tua checklist pratica.
- Inventaria ogni nome host e preserva i record DNS non correlati.
- Testa il routing del nome host prima del cutover pubblico.
- Scegli e automatizza una sfida di certificato adeguata.
- Pianifica le modifiche TTL e la transizione dei dati.
- Verifica DNS e TLS tramite controlli separati.
- Conserva l'accesso per il rollback e risolvi le nuove scritture prima di tornare indietro.
I dettagli che contano.
La modifica di un record A attiva HTTPS?+
No. DNS sceglie un endpoint; quell'endpoint necessita comunque del corretto routing del nome host e di un certificato valido e installato.
Posso ripristinare solo il record DNS se qualcosa si rompe?+
Il traffico può essere reindirizzato, ma le scritture dell'applicazione richiedono una gestione separata. Definisci un piano di rollback o riconciliazione dei dati prima della migrazione.
Un certificato wildcard è sempre necessario?+
No. Scegli i nomi del certificato e la convalida in base ai nomi host effettivi. Un wildcard ha requisiti specifici di copertura e convalida; non è una scorciatoia universale per la migrazione.
Vai alla fonte.
Questi riferimenti supportano i concetti tecnici di questa guida. Segui la documentazione corrente prima di modificare un sistema di produzione.
- Let's Encrypt: tipi di sfida letsencrypt.org
- IETF RFC 1034: concetti e funzionalità di DNS datatracker.ietf.org
- Mozilla MDN: Transport Layer Security developer.mozilla.org
Guida editoriale di SwissOctet. Gli esempi sono illustrativi. Le specifiche di servizio, le opzioni disponibili e le condizioni contrattuali devono essere verificate separatamente.