La « propagation DNS » dure au maximum le TTL de l'ancien enregistrement : 1 heure si le TTL était de 3 600 secondes, quelques minutes s'il était de 300. Rien ne se propage réellement : vos serveurs DNS sont à jour immédiatement, ce sont les caches des résolveurs qui gardent l'ancienne valeur jusqu'à expiration du TTL. Le changement de serveurs DNS (NS) est plus long, car son TTL est fixé par le registre : 48 heures pour un .com.
Les délais de « 24 à 48 heures » affichés par les hébergeurs sont des plafonds prudents. OVHcloud annonce par exemple jusqu'à 24 heures pour une modification de zone et jusqu'à 48 heures pour une modification des serveurs DNS. En pratique, vous pouvez prévoir et raccourcir ce délai.
Ce qui se passe vraiment quand vous modifiez un enregistrement
Quand un internaute visite votre-domaine.fr, son ordinateur interroge un résolveur (celui du FAI, de l'entreprise, ou un résolveur public comme 1.1.1.1 ou 8.8.8.8). Le résolveur interroge vos serveurs DNS faisant autorité, obtient la réponse et la garde en cache pendant la durée indiquée par le TTL (Time To Live), en secondes.
Quand vous modifiez l'enregistrement :
- vos serveurs faisant autorité servent la nouvelle valeur dès que la zone est rechargée, en général en quelques secondes ou minutes ;
- chaque résolveur qui avait l'ancienne valeur en cache continue de la servir jusqu'à la fin du TTL ;
- à l'expiration, il redemande et obtient la nouvelle valeur.
Concrètement, des milliers de caches expirent chacun à leur rythme, selon le moment où ils ont interrogé votre zone. D'où l'impression que « ça marche chez moi mais pas chez mon client ».
Combien de temps, selon le type de changement
| Changement | Délai maximal réel | Ce qui le fixe |
| Modification d'un enregistrement existant (A, MX, CNAME, TXT) | TTL de l'ancien enregistrement | Vous, dans la zone |
| Ajout d'un enregistrement qui n'existait pas | TTL de la réponse négative, si quelqu'un l'a demandé avant sa création | Champ minimum et TTL du SOA de la zone (RFC 2308) |
Changement de serveurs DNS (NS) d'un .com | Jusqu'à 48 heures | TTL NS de la zone .com : 172 800 secondes, relevé |
Changement de serveurs DNS (NS) d'un .fr | De l'ordre d'une heure, plus le délai de traitement du registrar | TTL NS de la zone .fr : 3 600 secondes, relevé |
| Ajout ou retrait d'un DS (DNSSEC) | TTL du DS | Registre : 86 400 s en .com, 3 600 s en .fr, relevés |
Nous avons relevé ces TTL en interrogeant directement les serveurs des registres (a.gtld-servers.net pour le .com, d.nic.fr pour le .fr). Pour un changement de NS, ajoutez le temps que met le registrar à transmettre la modification au registre. Certains résolveurs plafonnent aussi les TTL longs, ce qui peut raccourcir l'attente.
1. Interrogez directement le serveur faisant autorité
C'est la référence. S'il ne renvoie pas la nouvelle valeur, inutile d'attendre : l'erreur est dans la zone.
dig +short NS votre-domaine.fr
dns200.anycast.me.
ns200.anycast.me.
dig +short A votre-domaine.fr @ns200.anycast.me
203.0.113.20
2. Interrogez les grands résolveurs publics
dig A votre-domaine.fr @1.1.1.1
dig A votre-domaine.fr @8.8.8.8
dig A votre-domaine.fr @9.9.9.9
Dans la section ANSWER, le deuxième champ est le TTL restant dans le cache de ce résolveur :
votre-domaine.fr. 1873 IN A 203.0.113.10
Ici, le résolveur gardera l'ancienne adresse encore 1 873 secondes, soit environ 31 minutes. Vous savez exactement quand il basculera. Notre tutoriel pour lire un résultat dig détaille chaque ligne.
3. Comparez le numéro de série du SOA
OVHcloud recommande cette méthode : le numéro de série du SOA change à chaque modification de la zone.
dig +short SOA votre-domaine.fr
dns200.anycast.me. tech.ovh.net. 2026110501 86400 3600 3600000 300
Si le numéro (2026110501) correspond à celui affiché dans l'éditeur de zone de l'espace client, la modification est publiée. S'il est plus ancien, attendez ou revalidez la zone.
4. Utilisez un « propagation checker »
Les outils en ligne de vérification de propagation interrogent une série de résolveurs dans plusieurs pays et affichent leurs réponses. Ils donnent une photo utile, mais partielle : ils ne voient pas le cache du résolveur de votre client ou de votre entreprise. Notre DNS Lookup affiche les enregistrements actuels et leur TTL.
Raccourcir le délai : baisser le TTL avant la migration
La seule vraie façon d'accélérer est d'anticiper. La méthode :
- J-2 ou J-1 : baissez le TTL des enregistrements que vous allez modifier à 300 secondes (5 minutes). Chez OVHcloud, le TTL se règle par enregistrement, ou pour toute la zone via « Actions sur ma zone » puis « Modifier le TTL par défaut ».
- Attendez au moins l'ancien TTL. Si l'ancien TTL était de 86 400 secondes, les caches garderont l'ancienne durée pendant 24 heures. Baisser le TTL le jour même ne sert à rien.
- Jour J : faites la modification. Les caches basculent en 5 minutes au plus.
- Gardez l'ancien serveur actif quelques heures : certains résolveurs ne respectent pas strictement le TTL.
- Après stabilisation : remontez le TTL (3 600 secondes est une valeur courante) pour réduire la charge et la dépendance aux serveurs DNS.
Ce scénario est déroulé de bout en bout dans notre guide pour migrer ses DNS d'OVH vers Cloudflare sans downtime.
Le cas particulier du changement de serveurs DNS
Changer les NS diffère d'une modification d'enregistrement. Le TTL qui compte n'est pas celui de votre zone, mais celui de la délégation publiée par le registre, que vous ne contrôlez pas. Pour un .com, il est de 48 heures. Pendant cette période, une partie des résolveurs interroge encore les anciens serveurs DNS.
Pour que ce soit transparent :
- recréez la zone à l'identique chez le nouvel hébergeur avant de changer les NS ;
- gardez l'ancienne zone active et synchronisée pendant au moins 48 heures ;
- si DNSSEC est actif, retirez le DS avant le changement de NS, sinon les résolveurs validants renverront SERVFAIL.
Les mêmes précautions s'appliquent lors d'un changement de registrar : voir transférer un nom de domaine sans coupure.
Vider les caches locaux
Si les résolveurs publics renvoient la nouvelle valeur mais pas votre poste, le cache est local :
- macOS :
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Windows :
ipconfig /flushdns
- Navigateur : Chrome garde son propre cache, vidable depuis
chrome://net-internals/#dns.
Pour les résolveurs publics, Google Public DNS et Cloudflare proposent une page de purge du cache pour un nom donné. Les résolveurs des FAI, eux, suivront le TTL.
Surveiller les changements DNS
Une modification qui ne « se propage » pas cache parfois une erreur dans la zone, ou un changement fait par quelqu'un d'autre. Domains Defender relève vos enregistrements DNS à intervalle régulier et vous alerte quand un NS, A, MX ou TXT change. Voir les plans.
Questions fréquentes
Combien de temps prend la propagation DNS ?
Au maximum le TTL de l'ancien enregistrement, souvent une heure. Pour un changement de serveurs DNS, jusqu'à 48 heures en .com, de l'ordre d'une heure en .fr une fois la modification transmise au registre.
Propagation DNS chez OVH : pourquoi OVH annonce 24 à 48 heures ?
Ce sont des maximums prudents : 24 heures pour une modification de zone, 48 heures pour un changement de serveurs DNS. Le délai réel dépend du TTL, que vous pouvez baisser dans l'éditeur de zone OVHcloud.
Peut-on forcer la propagation DNS ?
Non, vous ne pouvez pas vider les caches des résolveurs des autres. Vous pouvez seulement baisser le TTL à l'avance, purger le cache de Google Public DNS et de Cloudflare, et vider vos caches locaux.
Quel outil pour vérifier la propagation DNS ?
dig sur le serveur faisant autorité puis sur 1.1.1.1, 8.8.8.8 et 9.9.9.9 donne la réponse et le TTL restant. Un outil en ligne de type « propagation checker » complète cette vue sur d'autres pays.