Avant de commencer
Identifiez le titulaire du domaine, le registrar, les serveurs de noms actuels et le fournisseur de messagerie. Exportez la zone DNS et gardez une copie cohérente des fichiers et de la base SQL. Ne partagez pas de code de transfert dans une demande publique.
Faire l’inventaire avant de modifier
Relevez les noms utilisés par le site, les sous-domaines, le courrier et les applications tierces. Conservez valeurs, types, priorités et TTL dans un document daté. Photographier seulement la page d’accueil ne suffit pas : certains TXT valident une propriété ou un service discret. Vérifiez également les accès permettant de restaurer la configuration précédente. Ne supprimez pas l’ancien hébergement avant d’avoir contrôlé la nouvelle destination.
Distinguer adresse web et routage du courrier
A associe un nom à une IPv4 ; AAAA fait de même pour IPv6. Un CNAME référence un autre nom, pas une URL avec un chemin. MX indique les serveurs qui reçoivent les messages avec leur priorité. Si vous déplacez seulement le site, préservez les MX et les enregistrements de la messagerie. Modifier les serveurs de noms sans reproduire toute la zone peut couper un service qui n’avait aucun lien avec la migration web.
Préparer la destination et le moment de bascule
Copiez les fichiers et la base, puis testez l’application et HTTPS à destination. Pour une boutique ou un espace membre, planifiez un gel des écritures afin d’éviter deux bases divergentes. Diminuer un TTL à l’avance peut réduire certains délais de cache ; cela n’efface pas les réponses déjà conservées et ne garantit pas une propagation instantanée. Choisissez une fenêtre où l’équipe peut vérifier les deux environnements.
Préserver l’authentification des e-mails
SPF est publié en TXT et décrit les expéditeurs autorisés. DKIM utilise une clé publique liée à un sélecteur. DMARC définit une politique et s’appuie sur l’alignement du domaine visible avec SPF ou DKIM. Conservez les valeurs du fournisseur de messagerie ; n’ajoutez pas plusieurs politiques SPF séparées pour le même nom. Après bascule, testez la réception, l’envoi et les résultats d’authentification sans exposer de clés privées.
Traiter la délégation et DNSSEC ensemble
Changer les serveurs de noms chez le registrar modifie la délégation ; cela ne transfère pas le titulaire du domaine ni son hébergeur. Si DNSSEC est actif, coordonnez les clés et les enregistrements DS avec les fournisseurs concernés. Un DS incompatible peut rendre la zone invalide pour les résolveurs validants. Faites confirmer la procédure avant de changer la délégation et conservez un accès de secours au registrar.
Contrôler puis fermer l’ancien environnement
Vérifiez les réponses A, AAAA, MX et TXT depuis plusieurs résolveurs, puis le site, les formulaires et la messagerie. Une vérification DNS ne remplace pas un test fonctionnel. Surveillez aussi l’ancien environnement pendant la transition et documentez les critères de retour. Préparez votre demande CubixServ en précisant les services à déplacer : le périmètre DNS, les accès et l’assistance sont convenus avant toute intervention.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Seul le site déménage | Conservez la messagerie et ses enregistrements, puis changez uniquement les noms web concernés. |
| Toute la zone change de fournisseur | Reproduisez tous les enregistrements et coordonnez DNSSEC avant la délégation. |
| Le site reçoit des commandes | Figez les écritures, faites une dernière copie cohérente et définissez les contrôles avant réouverture. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.