Propagation DNS : combien de temps et comment vérifier

Propagation DNS : de quoi parle-t-on exactement

Un enregistrement DNS ne change pas partout au même instant. Quand une zone est modifiée — nouveau serveur de noms chez le registrar, nouvelle adresse IP pour un enregistrement A, ajout d’un CNAME — cette modification part du serveur DNS faisant autorité, mais chaque résolveur intermédiaire (celui du fournisseur d’accès du visiteur, celui d’un réseau d’entreprise, celui d’un VPN) garde sa propre copie en cache pendant une durée fixée par le TTL (Time To Live) de l’enregistrement. Tant que ce cache n’a pas expiré, le résolveur continue de répondre avec l’ancienne valeur, même si la nouvelle est déjà en place côté hébergeur.

Ce mécanisme n’est pas un bug ni un retard de l’hébergeur : c’est la conception même du DNS, pensée pour limiter le nombre de requêtes vers les serveurs faisant autorité. La conséquence directe est qu’un même domaine peut pointer vers deux adresses différentes selon le visiteur, pendant une fenêtre de temps qui dépend presque uniquement des TTL en vigueur avant le changement.

Combien de temps dure la propagation DNS en pratique

Trois cas de figure, avec des durées très différentes :

Changement d’un enregistrement A ou CNAME (le domaine reste chez le même registrar, seule la cible change) : la propagation suit le TTL affiché sur l’enregistrement avant modification. Un TTL à 3 600 secondes (1 heure, valeur par défaut chez la plupart des registrars) donne une propagation quasi complète en 1 à 4 heures. Un TTL laissé à 86 400 secondes (24 heures, autre valeur par défaut fréquente) peut faire persister l’ancienne réponse jusqu’à 24 heures chez certains résolveurs.
Changement des serveurs de noms (nameservers) au niveau du registrar, typique d’une migration vers un nouvel hébergeur : les caches des résolveurs de zone du domaine lui-même s’ajoutent à ceux des enregistrements. Compter 4 à 24 heures pour l’essentiel du trafic, jusqu’à 48 heures pour une couverture quasi totale, certains résolveurs de FAI conservant des TTL de zone volontairement longs.
Ajout d’un sous-domaine ou d’un enregistrement MX (nouvelle boîte mail, nouveau service) : propagation nettement plus rapide, car aucun cache négatif (« ce nom n’existe pas ») ne doit expirer — moins de 2 heures dans la majorité des cas observés.

Le point commun aux trois cas : la durée dépend de la configuration DNS avant le changement, pas d’un délai universel appliqué par le registrar ou l’hébergeur.

Comment vérifier où en est la propagation

Un test depuis un seul navigateur ne renseigne que sur un seul résolveur, potentiellement celui qui a déjà mis à jour son cache. Pour avoir une vue représentative, deux méthodes complémentaires :

Un service de vérification DNS multi-résolveurs interroge simultanément des dizaines de serveurs DNS répartis dans le monde et affiche, pour chacun, la réponse actuellement en cache. C’est la méthode la plus rapide pour visualiser l’avancement réel plutôt que de deviner depuis son propre poste.
Une requête directe en ligne de commande (nslookup domaine.fr 8.8.8.8 ou dig domaine.fr @1.1.1.1) interroge un résolveur public précis, en contournant le cache local de la machine ou du routeur. Comparer le résultat entre un résolveur public (Google, Cloudflare) et le résolveur du FAI habituel permet d’isoler si le retard vient d’un cache local ou d’un résolveur particulier qui n’a pas encore rafraîchi sa copie.

Un écart de résultat entre deux résolveurs interrogés à la même minute n’est pas une anomalie : c’est la définition même d’une propagation en cours.

Propagation qui semble bloquée : les causes réelles à écarter une à une

Passé le délai attendu pour le TTL en jeu, plusieurs causes distinctes — fréquemment confondues entre elles — expliquent qu’un domaine ne bascule toujours pas :

Le changement de serveurs de noms n’a pas réellement été enregistré côté registrar. Une simple vérification via dig NS domaine.fr ou l’interface du registrar confirme si les nouveaux nameservers sont bien effectifs, avant de chercher une explication plus complexe.
Le cache local du poste ou du routeur n’a pas été purgé. Le cache DNS du système d’exploitation, celui du navigateur et celui de la box internet peuvent chacun conserver l’ancienne réponse au-delà du TTL déclaré par le résolveur amont, en particulier sur les box grand public dont l’implémentation du cache DNS est parfois approximative.
Le TTL a été laissé à une valeur élevée avant le changement, faute d’avoir été abaissé en amont d’une migration planifiée — le cas le plus fréquent, traité dans la section suivante.
L’enregistrement lui-même contient une erreur : IP incorrecte, type d’enregistrement erroné (AAAA au lieu de A), ou conflit entre un CNAME et un autre enregistrement sur le même nom, ce qui n’est pas un problème de délai mais de configuration.

Distinguer ces quatre causes évite d’attendre inutilement un délai supplémentaire quand le blocage vient en réalité d’une configuration à corriger.

Erreurs à éviter pendant l’attente

Deux réflexes aggravent systématiquement une propagation déjà en cours plutôt que de l’accélérer :

Modifier de nouveau l’enregistrement avant l’expiration du TTL précédent. Chaque modification relance un nouveau cycle de cache pour les résolveurs qui n’avaient pas encore récupéré la valeur précédente, ce qui prolonge la période d’incohérence au lieu de la raccourcir.
Couper l’ancien serveur ou l’ancien hébergement immédiatement après le changement. Tant que la propagation n’est pas terminée, une partie des visiteurs continue d’être dirigée vers l’ancienne cible. La couper prématurément transforme un délai de propagation normal en interruption de service visible, alors que le maintien en parallèle de l’ancien et du nouvel hébergement pendant 48 heures ne coûte rien de plus qu’un abonnement encore actif.

Réduire le délai de propagation avant un changement planifié

Pour un changement de serveurs ou d’adresse IP prévu à l’avance (migration d’hébergeur, passage à un nouveau serveur mail), le levier le plus efficace se joue avant le changement lui-même : abaisser le TTL de l’enregistrement concerné à une valeur basse (300 secondes, soit 5 minutes) au moins 24 à 48 heures avant l’opération. Cette réduction doit elle-même se propager, d’où le délai d’anticipation — un TTL modifié la veille au soir pour une bascule le lendemain matin n’a pas eu le temps de remplacer les caches encore chargés avec l’ancienne valeur, plus longue.

Une fois la bascule effectuée et la propagation confirmée sur l’essentiel des résolveurs testés, remonter le TTL à sa valeur habituelle (3 600 secondes ou plus) limite la charge de requêtes renvoyées vers les serveurs faisant autorité sur le long terme.

Propagation DNS et migration d’hébergeur : le point de vigilance

La propagation DNS est l’étape la plus fréquemment sous-estimée d’une migration vers un nouvel hébergeur : le site fonctionne correctement sur le nouveau serveur, mais une partie du trafic continue d’atteindre l’ancien pendant plusieurs heures, ce qui peut donner l’impression à tort que la migration a échoué. Garder les deux hébergements actifs en parallèle pendant la fenêtre de propagation, comme évoqué plus haut, reste la seule façon d’éviter une coupure pendant cette phase — une sauvegarde complète avant la bascule permet de revenir en arrière sans perte si un problème apparaît côté nouveau serveur pendant cette même fenêtre.

Ce délai de propagation fait aussi partie des critères à vérifier avant de choisir un nouvel hébergeur : la clarté de la documentation sur la gestion des serveurs de noms et la réactivité du support en cas de blocage pèsent autant que le prix ou les ressources allouées, un point détaillé dans le comparatif des meilleurs hébergeurs web.