Après une migration site, le moment où l’on décide de changer DNS est souvent le plus sensible. Une mauvaise mise à jour de la zone DNS, un TTL mal anticipé ou une vérification incomplète peuvent provoquer une erreur DNS, des indisponibilités temporaires et une perte de trafic.
Pour éviter ces problèmes, il faut traiter le basculement DNS comme une étape technique à part entière. Voici la méthode la plus sûre pour effectuer le changement proprement, réduire la propagation DNS et maintenir votre site accessible pendant toute la transition.
Préparer la zone DNS avant le basculement
La plupart des incidents ne surviennent pas au moment du changement, mais en amont, lorsque la configuration n’a pas été correctement préparée. Avant de changer DNS, commencez par inventorier tous les enregistrements de votre zone DNS actuelle : A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, SRV et éventuellement les sous-domaines techniques.
Cette étape est essentielle, car une migration réussie ne concerne pas seulement le site principal. Un oubli sur un sous-domaine, sur l’email ou sur une validation de service tiers peut entraîner une erreur DNS difficile à diagnostiquer. Si vous souhaitez cadrer l’ensemble du processus, consultez cette ressource dédiée à la migration de site sans coupure.
Avant toute modification, vérifiez notamment :
- l’adresse IP du nouveau serveur ;
- les enregistrements du domaine racine et du sous-domaine www ;
- les redirections prévues côté serveur ;
- les entrées mail pour ne pas interrompre la messagerie ;
- les enregistrements TXT liés à la sécurité et aux outils tiers.
Il est également recommandé d’exporter la configuration existante et de conserver une copie de secours. En cas d’erreur, vous pourrez restaurer rapidement la zone DNS précédente.
Enfin, assurez-vous que le nouveau serveur est pleinement fonctionnel avant le basculement. Le DNS ne doit jamais servir à tester un hébergement encore incomplet. Le site doit déjà répondre correctement, afficher la bonne version, charger ses ressources et fonctionner avec ses bases de données. Pour bien comprendre ces mécanismes, un rappel sur les bases du DNS et de la mise en réseau peut être utile.
Réduire le TTL pour maîtriser la propagation DNS
Le TTL (Time To Live) détermine combien de temps les résolveurs et les caches conservent une réponse DNS avant de demander une mise à jour. Si ce délai est trop long, la propagation DNS sera plus lente et les internautes pourront continuer à voir l’ancienne destination pendant plusieurs heures, voire plus.
La bonne pratique consiste à réduire le TTL des enregistrements concernés 24 à 48 heures avant de changer DNS. Par exemple, si votre TTL habituel est de 3600 ou 14400 secondes, vous pouvez temporairement le descendre à 300 secondes. Ainsi, au moment du basculement, les caches expireront plus vite et la nouvelle IP sera prise en compte plus rapidement.
Attention toutefois : modifier le TTL à la dernière minute ne produit pas d’effet immédiat. Les anciennes valeurs ont déjà pu être mises en cache. C’est pour cette raison qu’il faut anticiper.
Voici le schéma recommandé :
- J-2 : réduction du TTL sur les enregistrements critiques ;
- J-1 : vérification complète du nouveau serveur ;
- Jour J : mise à jour de la zone DNS ;
- J+1 : surveillance de la propagation DNS ;
- J+2 ou J+3 : retour à un TTL plus élevé si tout est stable.
Ce pilotage réduit fortement le risque d’erreur DNS prolongée. Il permet aussi de conserver une meilleure maîtrise de la fenêtre de transition, notamment sur les sites professionnels où chaque minute d’indisponibilité peut avoir un impact commercial.
Changer DNS sans provoquer d’erreur de résolution
Quand le nouveau serveur est prêt et que le TTL a été anticipé, vous pouvez changer DNS. Cette opération peut prendre deux formes : modifier les serveurs de noms chez le registrar, ou mettre à jour uniquement certains enregistrements de la zone DNS si vous conservez le même fournisseur DNS.
Dans les deux cas, l’objectif est d’éviter toute incohérence. Une erreur DNS apparaît souvent lorsque :
- le domaine racine pointe vers la nouvelle IP mais pas le www ;
- les nameservers sont changés sans avoir recréé toute la zone ;
- une entrée A est correcte, mais un CNAME reste dirigé vers l’ancien environnement ;
- des entrées mail ont été omises ;
- la configuration DNSSEC ou certains enregistrements techniques n’ont pas été reproduits.
La règle est simple : ne basculez jamais avant d’avoir comparé l’ancienne et la nouvelle configuration ligne par ligne. Si vous changez de prestataire DNS, recréez l’intégralité de la zone DNS sur le nouveau service avant d’activer les nouveaux serveurs de noms.
Profitez aussi de cette étape pour revoir la gestion du nom de domaine. Un bon pilotage du registrar, des nameservers et des accès d’administration réduit les risques d’erreur humaine pendant la migration.
Autre point crucial : gardez l’ancien hébergement actif pendant toute la durée de la propagation DNS. Même si une partie du trafic arrive déjà sur le nouveau serveur, certains utilisateurs ou résolveurs peuvent encore pointer vers l’ancienne infrastructure. Couper l’ancien service trop tôt est l’une des causes les plus fréquentes d’indisponibilité partielle.
Vérifier le site, le SSL et les services après propagation
Une fois la modification effectuée, ne considérez pas le travail comme terminé. La propagation DNS n’est pas instantanée, et il faut contrôler que tous les services répondent correctement depuis différents réseaux et localisations.
Commencez par tester :
- le domaine principal ;
- la version www ;
- les sous-domaines importants ;
- les formulaires ;
- l’envoi et la réception d’emails ;
- les accès au back-office ;
- les ressources statiques comme les images, CSS et scripts.
Surveillez également les messages du type serveur introuvable, mauvais certificat, redirection en boucle ou contenu mixte. Après un changement d’IP ou de serveur, il est indispensable de vérifier le certificat SSL après le changement DNS. Un certificat mal installé ou non réémis peut donner l’impression d’une erreur DNS alors que le problème se situe en réalité au niveau HTTPS.
Pour les sites à fort enjeu, il est recommandé d’utiliser plusieurs outils : commandes dig ou nslookup, plateformes de vérification DNS mondiales, monitoring HTTP et contrôle des journaux serveur. L’objectif est de valider à la fois la résolution DNS, l’accessibilité web et la cohérence applicative.
Pendant cette phase, continuez à comparer les réponses entre ancien et nouveau serveur si nécessaire. Si une anomalie apparaît, vous pourrez intervenir avant qu’elle n’impacte massivement vos visiteurs.
Bonnes pratiques pour limiter les erreurs et préserver l’uptime
Le succès d’une migration site se mesure autant à la qualité du nouveau serveur qu’à la fluidité du basculement. Pour changer DNS sans incident, il faut penser en termes de continuité de service, de contrôle et de réversibilité.
Voici les meilleures pratiques à retenir :
- préparer la zone DNS complète avant toute modification ;
- baisser le TTL suffisamment tôt ;
- tester le nouveau serveur avant la mise en production ;
- éviter de couper l’ancien hébergement trop rapidement ;
- contrôler la propagation DNS sur plusieurs points géographiques ;
- vérifier le SSL, les redirections et les emails ;
- documenter les changements pour pouvoir revenir en arrière si besoin.
Ces réflexes sont indispensables pour limiter les erreurs et préserver l’uptime. Un site qui reste accessible pendant sa transition protège à la fois son référencement, son chiffre d’affaires et la confiance de ses utilisateurs.
En pratique, le changement DNS ne doit jamais être improvisé. C’est une opération courte en apparence, mais stratégique dans ses effets. Plus votre préparation est rigoureuse, moins la propagation DNS sera source d’incertitude.
Vous préparez une migration site ou un changement d’infrastructure ? Mettez en place une checklist précise, sécurisez votre zone DNS et planifiez votre basculement pour changer DNS sans coupure ni erreur DNS.