Migration DNS vers Cloudflare : la checklist qui évite trois heures de black-out

La migration DNS vers Cloudflare a la réputation d'être triviale : importer la zone, pointer les serveurs de noms, attendre qu'elle se propage. Les équipes qui ont été évanouies pendant trois heures ont suivi exactement ce scénario. Le problème est que « trivial » décrit le cas parfait, et la production est rarement parfaite.

Ce que l'importation automatique ne fait pas pour vous

Lorsque vous ajoutez un domaine à Cloudflare, la plateforme interroge les serveurs faisant autorité du fournisseur actuel et tente d'importer tous les enregistrements de la zone. Le résultat est une liste d’enregistrements qui semble complète, et qui l’est presque toujours. C’est dans le « presque » que réside le risque.

Les enregistrements de type TLSA, utilisés pour DANE (authentification d'entité nommée DNS), ne sont souvent pas importés. La même chose se produit avec certains enregistrements SRV avec des configurations non standard, les enregistrements CAA avec plusieurs indicateurs ou valeurs inhabituelles, et tout enregistrement servi par le fournisseur précédent via une réponse non standard. L'importation Cloudflare est un point de départ, pas une garantie de fidélité.

Le protocole correct est le suivant : après l'importation, exportez la zone fournisseur actuelle au format BIND (la plupart des fournisseurs le proposent) et comparez manuellement les deux ensembles d'enregistrements. Des outils tels que diff sur le fichier de zone exporté révèlent ce que l'importation a manqué. Cette étape prend vingt minutes et évite de découvrir, après le retournement des serveurs de noms, que le certificat de messagerie a cessé de se valider car un enregistrement TLSA est manquant.

Proxy Cloudflare et services non HTTP

Cloudflare fonctionne selon deux modes pour chaque enregistrement A ou AAAA : proxy (le trafic passe par le réseau de Cloudflare, la véritable IP est masquée) et DNS uniquement (résolution pure, sans intermédiation). Les enregistrements MX importés sont DNS uniquement par défaut, ce qui est correct car SMTP ne passe pas par le proxy Cloudflare.

Le problème apparaît avec les enregistrements A qui pointent vers des serveurs de messagerie ou tout service autre que HTTP/HTTPS. Un enregistrement A appelé mail.exemplo.com qui pointe vers le serveur SMTP peut être proxy accidentellement lors de la configuration, en particulier si quelqu'un examine les enregistrements et active le proxy par lots. Le résultat est que le serveur de messagerie expose désormais les IP Cloudflare au lieu de la véritable IP, et les connexions SMTP externes atteignent un proxy qui ne sait pas quoi en faire. L'erreur n'est pas immédiate : certains clients de messagerie réessayent, le délai d'attente prend quelques minutes et le problème apparaît intermittent avant de devenir cohérent.

La même chose se produit avec les bases de données exposées via DNS. Un enregistrement A qui se résout en un serveur MySQL ou PostgreSQL derrière le proxy renvoie l'adresse IP Cloudflare. L'application tente de se connecter au port 3306 ou 5432, le proxy refuse (il ne prend pas en charge ces ports par défaut) et la connexion échoue avec un timeout. Le service semble être en panne, mais le DNS « fonctionne » : il pointe simplement vers le mauvais endroit.

Avant d'inverser les serveurs de noms, examinez chaque enregistrement A et AAAA et confirmez le mode correct. La règle est simple : si le service à cette adresse ne répond pas exclusivement en HTTP/HTTPS sur les ports 80 et 443, le mode doit être DNS uniquement.

TTL et fenêtre de propagation

La propagation du serveur de noms n'est pas instantanée et la durée de vie des enregistrements dans le fournisseur actuel détermine le temps nécessaire aux résolveurs du monde entier pour supprimer l'ancien cache. Si vos enregistrements ont une durée de vie de 86 400 secondes (24 heures) – la norme pour de nombreux fournisseurs – et que vous activez les serveurs de noms maintenant, certains résolveurs continueront à servir les anciens enregistrements pendant 24 heures maximum, indépendamment de ce que Cloudflare dit déjà.

La bonne stratégie commence deux jours avant la migration. Réduisez la durée de vie de tous les enregistrements critiques à 300 secondes (cinq minutes) sur le fournisseur actuel. Attendez le temps équivalent au TTL d'origine : si les enregistrements étaient à 3600 secondes, attendez une heure ; s'ils étaient à 86400, attendez 24 heures. Ensuite seulement, activez les serveurs de noms. Par conséquent, lorsque le changement se produit, les caches du monde entier expirent dans un délai maximum de cinq minutes et tous les problèmes qui surviennent lors de la migration sont résolus rapidement : vous n'êtes pas obligé d'attendre que les caches de 24 heures expirent pendant que l'incident se produit.

Cette étape est la plus souvent ignorée car elle nécessite une planification préalable. Ceux qui arrivent la veille de la migration et constatent que les TTL sont à 86400 ont deux options : baisser le TTL et attendre 24 heures avant de continuer, ou accepter le risque d'une longue fenêtre de propagation. La deuxième option est la voie la plus courante vers une panne d’électricité qui dure plus longtemps qu’elle ne le devrait.

DNSSEC : le détail qui transforme la propagation en échec de validation

Si le domaine a DNSSEC actif chez le fournisseur actuel, la migration des serveurs de noms sans gérer les enregistrements DS chez le registraire entraîne un échec de validation sur tous les résolveurs qui vérifient DNSSEC. Le résolveur reçoit une notification indiquant que le domaine utilise DNSSEC (via l'enregistrement DS chez le registraire), interroge Cloudflare, reçoit les signatures signées avec les clés Cloudflare et rejette la réponse car les clés ne correspondent pas au DS qui pointe toujours vers le fournisseur précédent.

La séquence correcte comporte quatre étapes avec des fenêtres d'attente entre les deux. Tout d'abord, supprimez les enregistrements DS du registraire (pas auprès du fournisseur DNS, mais du registraire où le domaine est enregistré). Deuxièmement, attendez que la durée de vie des enregistrements DS expire, généralement entre une et quatre heures, selon l'enregistreur. Troisièmement, basculez les serveurs de noms vers Cloudflare. Quatrièmement, activez DNSSEC dans le tableau de bord Cloudflare et ajoutez les nouveaux enregistrements DS que la plateforme fournit au registraire. Sauter la période d'attente entre la première et la troisième étape est la cause la plus courante d'incidents DNSSEC lors des migrations.

Comment structurer la migration pour ne pas improviser sous la pression

La différence entre une migration qui se termine en trente minutes et une autre qui se transforme en un incident de trois heures est presque toujours organisationnelle. Les équipes performantes définissent à l'avance qui valide chaque étape, ce qui configure la restauration et quels sont les critères de réussite avant de déclarer la migration terminée.

La séquence opérationnelle qui fonctionne commence par la comparaison des zones entre le fournisseur actuel et Cloudflare, effectuée avant tout pivot. Les domaines avec SPF, DKIM et DMARC nécessitent une attention particulière : les enregistrements TXT peuvent contenir des guillemets ou des concaténations qui importent automatiquement le reformatage, interrompant ainsi la validation même si le contenu semble correct. Les enregistrements SRV pour des services tels que SIP, XMPP ou Minecraft nécessitent une vérification manuelle des champs de priorité et de poids.

Une fois les serveurs de noms retournés, le protocole de vérification comporte trois commandes qui doivent être exécutées en séquence. La commande dig @1.1.1.1 +short exemplo.com NS confirme que Cloudflare fait déjà autorité pour le domaine sur ce résolveur. La commande dig @8.8.8.8 +short mail.exemplo.com A vérifie que le journal de courrier électronique renvoie la véritable adresse IP du serveur, et non une adresse IP Cloudflare. Un test d'envoi d'e-mail à partir d'une adresse externe dans les trente premières minutes suivant le délai d'exécution clôture le cycle de vérification de base.