CF GarageLa règle d'or : la migration se joue avant le changement de serveurs de noms
Une migration DNS réussie se prépare en amont, jamais pendant. Le moment où vous remplacez les serveurs de noms chez le registrar n'est qu'une étape de bascule : tout ce qui compte (inventaire complet des enregistrements, TTL abaissés, DNSSEC neutralisé) se fait AVANT. Une zone bien préparée bascule sans incident ; une zone copiée à la hâte perd des emails pendant deux jours ou, pire, disparaît du DNS à cause d'un enregistrement DS orphelin.
Le déroulé de migration, étape par étape
- Faites l'inventaire complet des enregistrements, pas seulement du site. Exportez la zone depuis l'opérateur actuel (fichier de zone ou copie manuelle) et identifiez chaque type : A, AAAA, CNAME, MX, TXT (SPF, vérifications de domaine Google/Microsoft), SRV, CAA. Les scanners automatiques de Cloudflare ne voient que les enregistrements web les plus courants : un SRV de téléphonie ou un CNAME interne oublié ne se révèle qu'en production, en panne.
- Abaissez les TTL 24 à 48 heures avant. Passez les TTL des enregistrements clés à 300 secondes sur l'opérateur actuel. Si un correctif s'avère nécessaire pendant la bascule, il se propage en minutes au lieu d'heures.
- Créez la zone dans Cloudflare et recopiez tout, en nuage gris. Ajoutez le domaine, laissez le scan initial remplir la zone, puis vérifiez-le ligne par ligne contre votre inventaire. Recréez tout manquant, et mettez tous les enregistrements en DNS only (nuage gris) pour cette phase : la proxification viendra après, jamais pendant.
- Traitez le DNSSEC. Si la zone est signée chez l'opérateur actuel, retirez l'enregistrement DS chez le registrar et attendez sa propagation avant de changer les serveurs de noms. Un DS qui pointe vers des serveurs qui ne signent plus invalide la zone entière aux yeux des résolveurs validants.
- Basculez les serveurs de noms chez le registrar. Remplacez les NS actuels par la paire fournie par Cloudflare (vérifiez les noms exacts dans le dashboard, ils varient selon la zone). Le reste n'est que propagation : compte de 1 à 4 heures en pratique, jusqu'à 24-48 heures en théorie.
- Vérifiez le site et les emails avant de proxifier. Testez le site sur les deux familles d'adresses, envoyez et recevez des emails, vérifiez que les services tiers (CRM, téléphonie, outils qui interrogent le DNS) répondent. C'est le moment de corriger, avec la possibilité de revenir en arrière instantanément (les anciens NS sont encore connus des résolveurs).
- Proxifiez progressivement, puis durcissez le SSL/TLS. Passez les enregistrements web en nuage orange un à un, en vérifiant le site à chaque étape. Passez le mode SSL/TLS en Full (strict) avec un certificat valide sur l'origine, sinon c'est la porte ouverte à la boucle de redirection HTTPS.
Les pièges qui coûtent le plus cher
- Le DS DNSSEC oublié : c'est la panne la plus brutale de la migration. Le domaine cesse de résoudre pour les résolveurs qui valident, souvent pour une partie seulement des visiteurs, ce qui rend le diagnostic contre-intuitif. Toujours retirer le DS avant la bascule.
- Les enregistrements de messagerie approximatifs : un MX oublié ou un SPF tronqué se voit rarement immédiatement ; les emails partent en spam ou bounce pendant des semaines. Copiez MX, SPF, DKIM et DMARC caractère pour caractère, et gardez les hôtes de messagerie en nuage gris : proxifier un MX casse la remise. Notre guide sur les emails cassés après le proxy couvre ce cas en détail.
- Proxifier des hostnames non web : webmail, FTP, paneau d'admin d'hébergement, API avec clients legacy : derrière le proxy, ces services voient leurs ports non standards bloqués et leurs clients HTTP malveillants filtrés. Nuage gris par défaut, nuage orange par exception justifiée.
- Changer les serveurs de noms un vendredi 17 h : la propagation peut s'étaler sur 48 heures, période pendant laquelle les deux zones coexistent. Migrer en début de semaine, pendant les heures ouvrées, c'est pouvoir réagir pendant que l'ancienne zone est encore fraîche dans les caches.
- Compter sur le scan automatique : le scanner Cloudflare est bon pour les enregistrements web standards, aveugle pour le reste. La vérification ligne par ligne contre l'inventaire n'est pas optionnelle.
Questions fréquentes
Combien de temps dure une migration DNS vers Cloudflare ?
La manipulation prend moins d'une heure si la zone est préparée. La propagation qui suit le changement de serveurs de noms s'étale de 1 à 4 heures en pratique, jusqu'à 24-48 heures en théorie selon les TTL. D'où l'importance d'abaisser les TTL plusieurs jours avant : une anomalie se corrige alors en minutes.
Faut-il activer le proxy (nuage orange) dès la migration ?
Non, c'est le meilleur moyen de cumuler les incidents. Recréez d'abord toute la zone en nuage gris et validez que site et emails fonctionnent à l'identique. La proxification vient ensuite, enregistrement par enregistrement, avec vérification à chaque étape. Un problème apparait ? On sait quelle bascule l'a déclenché.
Que faire du DNSSEC pendant la migration ?
Retirez l'enregistrement DS chez le registrar avant de changer les serveurs de noms, puis réactivez DNSSEC une fois la zone servie par Cloudflare (qui fournit les nouveaux éléments DS). Laisser un DS orphelin invalide la zone aux yeux des résolveurs validants, avec des pannes partielles difficiles à diagnostiquer.
La migration peut-elle faire perdre mes emails ?
Uniquement si les enregistrements de messagerie sont mal recréés ou si les hôtes de messagerie sont proxifiés. MX, SPF, DKIM et DMARC copiés à l'identique et laissés en nuage gris, la messagerie ne voit rien. Les ennuis commencent quand on proxifie un MX ou un webmail, ou qu'un SPF est tronqué au recopiage.