Définir ce qui change réellement
Transférer un domaine vers un autre bureau d’enregistrement, changer les serveurs DNS faisant autorité, déplacer le site et changer de fournisseur de messagerie sont des opérations distinctes. Notez lesquelles sont prévues. Un changement d’hébergement Web n’exige pas automatiquement de déplacer les e-mails.
Notre modèle de passation comporte quatre lignes : gestion du domaine, DNS, site et messagerie. Pour chacune, indiquez les anciens et nouveaux prestataires, le responsable et les accès requis. L’expression « transfert du domaine » devient ainsi un périmètre de changement précis.
Sauvegarder l’inventaire
Documenter noms, valeurs, TTL, services et responsables.
Modifier les destinations
Réaliser les changements convenus et vérifier les services.
Fermer l’ancien dispositif
Nettoyer les références et les accès avant de libérer les ressources.
Un nouvel état vérifiable
Les nouvelles destinations sont confirmées, la messagerie nécessaire est préservée et aucun renvoi involontaire ne subsiste vers un service abandonné.
Modèle de travail pour une transition maîtrisée. L’inventaire, la bascule et la fermeture sont validés séparément.
Préserver explicitement les dépendances
Comparez tout import DNS automatique à l’inventaire existant. Cloudflare recommande de vérifier les enregistrements des services utilisés et de confirmer les valeurs de messagerie auprès du fournisseur concerné.
Sauvegardez la zone avant de la modifier et faites attribuer les enregistrements inexpliqués à un responsable. Une nouvelle agence ne doit pas deviner si une valeur TXT opaque reste nécessaire. Demandez une décision étayée. Une valeur inconnue n’est pas une raison suffisante pour la supprimer. [1]
Faites défiler le tableau horizontalement.
| Enregistrement ou domaine | Question avant migration | Validation |
|---|---|---|
| A, AAAA et CNAME du site | Quels noms doivent pointer vers le nouveau site ? | Vérifier adresse principale, www et sous-domaines convenus. |
| MX et destinations de messagerie | Le fournisseur de messagerie reste-t-il le même ? | Confirmer réception et envoi par des tests autorisés. |
| SPF, DKIM et DMARC | Quels services actifs utilisent ces valeurs ? | Contrôler l’authentification par circuit d’envoi. |
| Valeurs de service et de vérification | À quel service et compte appartiennent-elles ? | Conserver, remplacer ou justifier la suppression. |
| DNSSEC et délégation | Les serveurs DNS ou les clés changent-ils ? | Vérifier séparément résolution et chaîne de confiance. |
Une TTL courte ne remplace pas le calendrier
La TTL indique la durée pendant laquelle une réponse DNS peut être conservée en cache. La réduire ensuite n’efface pas rétroactivement les réponses déjà enregistrées.
Exemple de planification, pas délai universel : un enregistrement passe de 3 600 à 300 secondes. Réduire la TTL au moment exact de la bascule ne supprime pas l’heure de cache auparavant possible. Anticipez le changement et maintenez l’ancien service pendant une transition convenue. Les autres caches, la délégation et DNSSEC peuvent avoir leurs propres délais. [2]
Éviter les renvois vers des ressources libérées
Un enregistrement pointant vers une ressource abandonnée qu’un tiers peut récupérer peut permettre une prise de contrôle du sous-domaine. Un échec de résolution ne prouve pas, à lui seul, cette possibilité.
Pour chaque service retiré, notez le nom, la destination, le compte, le responsable et la décision de fermeture. Modifiez ou supprimez le renvoi de façon contrôlée, tenez compte des caches restants, puis libérez l’ancienne ressource. Vérifiez ensuite les liens dans les applications et documents. Veillez à ne pas arrêter un nouveau service utilisant légitimement le même nom. [3]
Intégrer DNSSEC au plan
Lors d’un changement de serveurs DNS, l’enregistrement DS de la zone parente doit correspondre aux clés DNSSEC. Une chaîne de confiance obsolète peut provoquer SERVFAIL chez les résolveurs validants.
Faites planifier la migration par le responsable DNS. Certains fournisseurs permettent une transition coordonnée avec signature active. Sinon, la désactivation temporaire et la réactivation doivent faire partie du même changement. Laisser DNSSEC désactivé durablement ne constitue pas une clôture satisfaisante. Si seul l’hébergement Web change, vérifiez d’abord si la chaîne de confiance est réellement concernée. [4] [5]
Clôturer après la validation
Une capture de la nouvelle page d’accueil ne constitue qu’une partie de la recette. Fixez un responsable, un moment de contrôle et un retour arrière. Le compte rendu distingue vérifications réalisées et points ouverts. Un test de messagerie non effectué reste ouvert.
- Comparer l’inventaire DNS avant et après le changement.
- Ouvrir site, www, redirections et sous-domaines convenus.
- Documenter les tests de messagerie autorisés et l’authentification.
- Contrôler DNSSEC et la délégation s’ils sont concernés.
- Supprimer les anciens renvois, puis libérer les ressources inutilisées.
- Retirer les accès d’agence et clés API devenus inutiles.
- Consigner les nouveaux responsables et la prochaine vérification.
Fiche de transmission DNS à compléter
Consignez la migration dans un document partagé. Le modèle CSV couvre le site, la messagerie, les enregistrements de vérification et DNSSEC. Ajoutez une ligne distincte pour chaque enregistrement DNS réellement utilisé. Le modèle ne contient aucun résultat de test et ne réalise aucune requête ni modification.
Relevez les valeurs actuelles et prévues dans les comptes des prestataires concernés. Notez la validation, le résultat attendu et la preuve effectivement obtenue. Un test non réalisé reste ouvert ; une TTL courte ou une page d’accueil accessible ne remplace pas la réception de l’ensemble des changements.
Conservez le fichier rempli dans votre propre espace protégé. N’y inscrivez aucun mot de passe, aucune clé API ni aucun autre identifiant secret. Ne transmettez pas les détails de votre infrastructure par le formulaire de contact public. [1] [2] [3] [5]
Faites défiler le tableau horizontalement.
| Domaine | À consigner avant le changement | À prouver après le changement |
|---|---|---|
| Site et www | Noms, anciennes et nouvelles destinations, responsables | Disponibilité et redirections convenues |
| Messagerie | MX, SPF, DKIM et DMARC pour chaque circuit d’envoi | Tests autorisés de réception et d’envoi ; authentification de l’expéditeur |
| Autres services | Fonction et compte responsable de chaque valeur de vérification | Décision confirmée de conserver, modifier ou supprimer |
| DNSSEC et anciens services | Délégation, clés concernées, plan de retrait et de retour arrière | Résolution cohérente ; nettoyage contrôlé des anciennes références |
Plus d’e-mails après un changement de serveurs de noms ?
Déterminez d’abord si le problème touche la réception, l’envoi ou un seul service expéditeur. Relevez l’heure et l’erreur exacte. Comparez ensuite la nouvelle zone DNS faisant autorité à l’inventaire sauvegardé et aux exigences du fournisseur de messagerie.
Ne modifiez pas plusieurs protections sur une simple supposition. Un problème de livraison ne justifie pas de désactiver globalement DMARC ou de supprimer des enregistrements inexpliqués. Documentez séparément la cause, la correction ciblée et le résultat. [1] [2] [4] [5]
Faites défiler le tableau horizontalement.
| Observation | Premier contrôle | Vérification suivante |
|---|---|---|
| Le site fonctionne, les e-mails entrants manquent | Les MX et leurs noms cibles sont-ils corrects dans la zone active ? | Contrôler un test de réception autorisé et l’état du fournisseur. |
| Le message arrive, l’authentification échoue | SPF et DKIM correspondent-ils au service expéditeur ? | Lire les en-têtes originaux et vérifier l’alignement DMARC. |
| Le DNS renvoie SERVFAIL | Délégation, DS et signatures DNSSEC concordent-ils ? | Vérifier la chaîne de confiance, sans seulement attendre les caches. |
| Certains réseaux voient encore les anciennes valeurs | Distinguer réponses autoritatives et réponses en cache. | Consigner TTL, heure de requête et résolveur. |