Après plusieurs années à gérer un portefeuille de domaines clients dispersé entre une dizaine de registrars différents, hérités d’autant de décisions prises au fil des projets, l’agence a décidé de consolider l’ensemble vers un unique registrar, pour simplifier la facturation, la gestion des renouvellements et la réactivité en cas d’incident. Cent domaines étaient concernés.
Cet article ne traite pas du transfert de propriété d’un domaine isolé, procédure déjà couverte en détail en 2020. Il détaille la méthode suivie pour migrer la gestion DNS de l’ensemble de ce portefeuille en lot, sans coupure de service constatée sur aucun des cent domaines concernés.
Étape 1 — Cartographier le portefeuille avant toute action
La première étape a consisté à établir un inventaire complet et précis de chaque domaine : registrar actuel, contenu exact de la zone DNS (via une extraction systématique par requêtes dig ciblées plutôt qu’une confiance aveugle dans un export d’interface, une leçon tirée d’un incident précédent sur ce même sujet), et TTL actuellement configuré sur chaque enregistrement.
Ce travail de cartographie, réalisé sur les cent domaines avant toute migration, a représenté à lui seul près d’une semaine de travail, mais a permis d’éviter la principale cause d’incident sur ce type d’opération : une zone incomplètement recréée faute de visibilité totale sur son contenu réel avant la bascule.
Étape 2 — Abaisser les TTL, une semaine avant la bascule
Pour chaque domaine, une semaine avant sa bascule programmée, le TTL de l’ensemble des enregistrements de la zone est abaissé à 300 secondes (contre souvent 3600 ou 86400 secondes en configuration par défaut). Cette étape, appliquée systématiquement et jamais sautée même pour les domaines jugés « simples », garantit qu’en cas de nécessité de rollback après la bascule, la propagation d’un retour à l’ancienne configuration se ferait également en quelques minutes plutôt qu’en plusieurs heures.
Étape 3 — Recréer la zone chez le nouveau registrar avant toute bascule de serveurs de noms
Point central de la méthode : la zone DNS complète est intégralement recréée chez le nouveau registrar avant tout changement des serveurs de noms du domaine. Cette zone recréée est vérifiée en parallèle de l’ancienne, en interrogeant directement les nouveaux serveurs de noms avant qu’ils ne soient déclarés faisant autorité pour le domaine.
dig @ns1.nouveau-registrar.fr exemple-client.fr mx
dig @ns1.nouveau-registrar.fr exemple-client.fr txt
dig @ns1.nouveau-registrar.fr www.exemple-client.fr aCette vérification, réalisée avant la bascule effective, permet de comparer terme à terme la nouvelle zone à l’ancienne pendant qu’aucun visiteur ne dépend encore d’elle, plutôt que de découvrir un écart après que le changement de serveurs de noms ait déjà commencé à se propager.
Étape 4 — Basculer les serveurs de noms, domaine par domaine
- Changement des serveurs de noms au niveau du registrar d’origine, un domaine à la fois plutôt qu’en masse.
- Vérification immédiate, via plusieurs résolveurs publics distincts, de la propagation effective vers les nouveaux serveurs de noms.
- Contrôle fonctionnel réel : chargement du site, test d’envoi d’email sur une adresse du domaine, vérification du certificat TLS.
- Passage au domaine suivant uniquement après validation complète du précédent.
Ce traitement domaine par domaine, plutôt qu’une bascule groupée de l’ensemble du portefeuille en une seule opération, a délibérément ralenti le calendrier global — six semaines au lieu des deux initialement envisagées — en échange d’une capacité à isoler immédiatement tout incident sur un domaine précis sans qu’il ne se propage ou ne se confonde avec d’autres bascules en cours simultanément.
Étape 5 — Vérification post-bascule et retour au TTL normal
Une fois la bascule d’un domaine validée et stable pendant 48 heures, son TTL est relevé vers une valeur normale de production (3600 secondes typiquement), et l’ancien registrar est marqué pour résiliation à l’échéance contractuelle en cours, sans résiliation anticipée qui aurait pu compromettre la possibilité d’un rollback tardif.
Une migration DNS en lot ne se gagne jamais sur la vitesse d’exécution. Elle se gagne sur la capacité à vérifier chaque domaine individuellement avant de considérer sa bascule comme définitivement acquise.
Pour aller plus loin
Sur les cent domaines migrés selon cette méthode, aucune coupure n’a été signalée par un client, et deux anomalies mineures (un enregistrement TXT de vérification tiers oublié dans la cartographie initiale) ont été détectées et corrigées pendant la phase de vérification, avant tout impact visible. La rigueur de l’étape de cartographie initiale reste, avec le recul, le facteur qui a le plus contribué à ce résultat.
