Changer d’hébergeur exige de contrôler la propagation des enregistrements. Le but est d’éviter toute coupure DNS visible pour les utilisateurs.
Je décris une méthode pratique, illustrée par l’expérience de Claire, administratrice qui a migré un site marchand sans interruption. Suivez ce fil conducteur pour répéter l’opération.
A retenir :
- Préparez le TTL avant le transfert pour réduire le délai propagation.
- Synchronisez le serveur DNS source et la nouvelle zone avant la mise à jour DNS.
- Vérifiez la résolution DNS depuis plusieurs lieux et purge le cache DNS si nécessaire.
- Prévoyez un plan de retour arrière et testez sur sous-domaine avant la transition finale.
Préparer le transfert DNS sans coupure
Avant toute action, réduisez le TTL des enregistrements critiques. Une valeur basse accélère la propagation DNS après changement.
Claire a mis le TTL de 86400 à 300 heures 48 heures avant le transfert. Cette mesure a réduit le délai propagation constaté par les visiteurs.
Analyser le TTL et l’impact du cache DNS
Cartographiez les enregistrements A, AAAA, CNAME et MX. Notez les TTL actuels et les points où le cache DNS peut conserver des valeurs obsolètes.
Liste de contrôle rapide :
- Identifier les enregistrements critiques.
- Consigner les TTL actuels et prévoir les nouvelles valeurs.
- Alerter les équipes dev et ops du calendrier du transfert.
- Documenter l’adresse IP de secours pour rollback.
Procédure pas à pas pour la mise à jour DNS
Migrer commence par préparer la zone sur le nouveau serveur DNS sans la publier. Comparez les enregistrements puis basculez la mise à jour DNS chez le registrar.
Voici les étapes exécutées par Claire et son équipe.
Étapes sur le registrar et synchronisation de zones
- Créer la zone complète sur le nouveau serveur DNS et tester la résolution DNS locale.
- Réduire le TTL 48 h avant changement.
- Mettre à jour les NS chez le registrar à l’heure planifiée.
- Surveiller la propagation et conserver les anciens serveurs actifs 24-48 h.
| Contexte | TTL initial | TTL recommandé | Impact |
|---|---|---|---|
| Site vitrine | 86400 | 300 | Propagation rapide, charge DNS accrue |
| API critique | 3600 | 120 | Clients reconnectent rapidement |
| MX (mail) | 86400 | 1800 | Risque limité, prévoir vérification |
| CNAME vers CDN | 300 | 300 | Pas de changement nécessaire |
Retour d’expérience : sur un site e-commerce, l’équipe a testé la zone sur un sous-domaine pour valider la configuration avant la bascule. Le test a duré 2 heures.
Valider la résolution DNS et gérer le cache
Après la mise à jour, vérifiez la résolution DNS depuis plusieurs régions. Utilisez dig, nslookup et services en ligne pour mesurer le délai propagation.
Un contrôle systématique réduit les risques d’une coupure DNS persistante.
Outils, purge et vérification
- Tester la résolution publique : dig +trace, Global DNS checkers.
- Purger le cache DNS local et du serveur récursif si nécessaire.
- Demander aux utilisateurs impactés un vidage DNS du navigateur.
- Surveiller les erreurs 5xx ou DNS timeout au niveau applicatif.
« Nous avons évité une panne grâce à la réduction du TTL avant la migration. »
Claire, administratrice réseau
Anticiper les problèmes et plan de retour arrière
Préparez une procédure de rollback. Gardez l’ancien serveur DNS actif pendant la fenêtre de propagation. Documentez chaque étape.
Mon avis : un plan clair réduit fortement le temps de restauration en cas de coupure DNS.
Plan de retour arrière et conseils pratiques
- Conserver les anciens NS et IP 48 heures après bascule.
- Prendre des captures de la zone avant modification.
- Notifier les parties prenantes et fournir contacts de support.
- Tester le rollback sur un sous-domaine avant intervention finale.
Retour d’expérience : lors d’une migration nocturne, un enregistrement mal copié a provoqué une erreur. Le rollback en 30 minutes a restauré le service.
Exemple WordPress pour noter l’opération : [dns_migration date= »2026-03-02″ status= »success » notes= »TTL réduit à 300 avant bascule »]
Insight final : planifier, tester et surveiller sont les trois actions qui minimisent le risque d’une coupure DNS.
Sources et lectures : IETF DNS extensions, Google Public DNS documentation.