Propagation DNS : combien de temps faut-il vraiment ?

Par CaptainDNS
Publié le 26 mars 2026

Diagramme montrant les délais réels de propagation DNS en fonction du TTL sur différents résolveurs publics

TL;DR

La « propagation DNS » n'existe pas en tant que mécanisme : le DNS ne pousse rien. Ce sont les caches des résolveurs qui expirent selon le TTL (Time To Live) configuré par l'administrateur de zone.
Le délai réel dépend du TTL de l'enregistrement modifié : 1 minute (TTL 60) à 24 heures (TTL 86400). Aucune raison technique ne justifie un délai de 48 heures.
Baisser le TTL à 300 secondes 48 heures avant un changement DNS élimine le mythe des « 24 à 48 heures ». Après modification, le nouvel enregistrement est visible partout en 5 minutes.
Vérifier en temps réel avec un outil multi-résolveurs permet de confirmer que le changement est effectif, résolveur par résolveur.

« Comptez 24 à 48 heures pour la propagation DNS. » Si vous avez déjà changé un enregistrement DNS, vous avez lu cette phrase. Sur les pages d'aide de votre registrar, dans un ticket de support, ou dans un tutoriel trouvé via un moteur de recherche. C'est probablement le conseil technique le plus répété sur Internet. C'est aussi l'un des plus trompeurs.

Le DNS ne « propage » rien. Il n'existe aucun mécanisme de diffusion dans le protocole DNS qui pousse les changements vers les résolveurs du monde entier. Ce qui existe, c'est un système de cache distribué avec une horloge d'expiration : le TTL. Quand vous modifiez un enregistrement, les résolveurs qui ont l'ancienne valeur en cache continuent de la servir jusqu'à expiration du TTL. Ensuite, ils interrogent le serveur faisant autorité et obtiennent la nouvelle valeur. C'est tout.

Le délai perçu est intégralement contrôlable. Si le TTL est de 5 minutes, le changement est visible partout en 5 minutes. S'il est de 24 heures, il faut attendre 24 heures. Le chiffre « 48 heures » ne correspond à aucune valeur de TTL standard. Il vient d'une époque révolue, celle des débuts du DNS commercial, où les registrars imposaient des TTL de 86 400 secondes (24 heures) et où les résolveurs des FAI ajoutaient parfois leurs propres délais.

Cet article va décomposer le mécanisme réel, chiffrer les délais exacts pour chaque valeur de TTL, et vous donner une méthode de migration DNS qui rend le délai prévisible et maîtrisé.

Vérifiez votre propagation DNS

Tester la propagation DNS Lancer un DNS Lookup

Le mythe des « 24 à 48 heures »

D'où vient ce chiffre ?

Pour comprendre l'origine du mythe, il faut remonter aux années 2000. À cette époque, les registrars comme Network Solutions, GoDaddy ou Gandi configuraient des TTL par défaut de 86 400 secondes (24 heures) sur les enregistrements qu'ils géraient. Certains registres de TLD (comme VeriSign pour .com et .net) mettaient à jour les fichiers de zone toutes les 12 heures. En cumulant ces deux facteurs, un changement de serveur NS pouvait effectivement prendre jusqu'à 36 heures pour être visible partout. Arrondir à « 48 heures » permettait de couvrir les cas limites.

Le problème, c'est que cette estimation est restée figée dans la documentation alors que l'infrastructure a changé. Aujourd'hui, les registres majeurs mettent à jour leurs zones en quelques minutes. Les registrars modernes proposent des TTL de 3 600 secondes (1 heure) par défaut, parfois 300 secondes. La réalité technique de 2026 n'a plus rien à voir avec celle de 2002.

Le mot « propagation » est un abus de langage

Le terme « propagation » suggère un processus actif de diffusion. Comme si un changement DNS était poussé de serveur en serveur, à la manière d'une mise à jour logicielle qui se déploie progressivement. Cette image mentale est fausse.

Le DNS fonctionne sur un modèle pull, pas push. Aucun serveur n'envoie de notification aux résolveurs pour leur dire « la valeur a changé ». Chaque résolveur récursif décide de lui-même quand il interroge le serveur faisant autorité, en fonction du TTL de l'enregistrement qu'il a en cache.

Voici ce qui se passe réellement quand un utilisateur tape captaindns.com dans son navigateur :

Le stub resolver de la machine locale vérifie son cache. S'il a une réponse valide (TTL non expiré), il la retourne immédiatement.
S'il n'a rien en cache, il transmet la requête au résolveur récursif configuré (celui du FAI, de Google, de Cloudflare, etc.).
Le résolveur récursif vérifie son propre cache. S'il a une réponse valide, il la retourne.
S'il n'a rien ou si le TTL est expiré, il lance une résolution complète : il interroge un serveur racine, puis le serveur TLD (.com), puis le serveur faisant autorité pour le domaine.
Le serveur faisant autorité retourne la réponse actuelle (le nouvel enregistrement si vous l'avez modifié) avec le TTL configuré.
Le résolveur met cette réponse en cache pour la durée du TTL et la retourne à l'utilisateur.

Le « délai de propagation » n'est rien d'autre que le temps restant avant l'expiration du cache. Si le résolveur a mis l'ancien enregistrement en cache il y a 30 minutes avec un TTL de 3 600 secondes, il faudra encore 30 minutes avant qu'il interroge de nouveau le serveur faisant autorité.

Diagramme de la résolution DNS hiérarchique : stub resolver, résolveur récursif, serveur racine, TLD, serveur faisant autorité

Le TTL : la vraie horloge de la propagation

Qu'est-ce que le TTL ?

Le TTL (Time To Live) est un champ numérique associé à chaque enregistrement DNS, exprimé en secondes. Il indique aux résolveurs combien de temps ils peuvent garder la réponse en cache avant de devoir la re-demander au serveur faisant autorité.

Le TTL est défini par l'administrateur de la zone DNS, pas par le protocole. C'est un choix d'exploitation. Chaque enregistrement dans une zone peut avoir son propre TTL. Vous pouvez configurer un TTL de 60 secondes sur un enregistrement A qui pointe vers un service en haute disponibilité, tout en gardant un TTL de 86 400 secondes sur un enregistrement MX qui ne change jamais.

La RFC 1035 (section 3.2.1) définit le TTL comme un entier non signé de 32 bits, soit une valeur maximale théorique de 2 147 483 647 secondes (environ 68 ans). En pratique, la RFC 2181 (section 8) recommande de traiter toute valeur supérieure à 2 147 483 647 comme 0. Les valeurs courantes vont de 60 à 86 400 secondes.

Pour vérifier le TTL actuel d'un enregistrement, utilisez dig :

dig captaindns.com A +noall +answer

La sortie ressemble à ceci :

captaindns.com.    3600    IN    A    76.76.21.21

Le nombre 3600 est le TTL restant en secondes. Attention : cette valeur décroît à chaque seconde. Si vous relancez la commande 10 secondes plus tard, vous verrez 3590. Quand elle atteint 0, le résolveur considère l'entrée expirée et interroge de nouveau le serveur faisant autorité.

Pour obtenir le TTL défini par le serveur faisant autorité (et non le TTL restant dans le cache du résolveur), interrogez directement le serveur autoritaire :

dig captaindns.com A @ns1.captaindns.com +noall +answer

Tableau des délais réels par TTL courant

Ce tableau donne le délai maximum entre un changement DNS et sa visibilité complète sur tous les résolveurs, en supposant que le résolveur a mis l'ancien enregistrement en cache juste avant la modification (pire cas).

TTL (secondes)	Durée lisible	Délai max de visibilité	Usage typique
60	1 minute	1 minute	Basculement automatique, haute disponibilité, services critiques
300	5 minutes	5 minutes	CDN, répartition de charge, pré-migration
900	15 minutes	15 minutes	Services cloud (AWS, GCP, Azure)
1800	30 minutes	30 minutes	Applications SaaS
3600	1 heure	1 heure	Défaut courant des registrars modernes (Cloudflare, Route 53)
14400	4 heures	4 heures	Défaut historique OVH, Gandi, certains panels cPanel
43200	12 heures	12 heures	Enregistrements stables rarement modifiés
86400	24 heures	24 heures	Enregistrements NS, enregistrements de zone stables, défaut historique

Le « 24 à 48 heures » du mythe correspond au pire cas d'un TTL de 86 400 combiné à un résolveur qui aurait mis la valeur en cache une seconde avant la modification. Dans ce scénario, le délai maximum est de 24 heures, pas 48. Les 48 heures sont un arrondi de précaution sans fondement technique.

Pourquoi certains résolveurs ignorent le TTL ?

Le protocole DNS (RFC 1035) exige que les résolveurs respectent le TTL. En pratique, quelques écarts existent.

TTL minimum imposé. Google Public DNS impose un plancher de 30 secondes. Si un serveur faisant autorité retourne un TTL de 0 ou de 10 secondes, Google le traite comme 30 secondes. Ce comportement est documenté dans leur FAQ technique. Cloudflare applique un plancher similaire. L'impact est négligeable pour la plupart des cas d'usage.

TTL maximum imposé. Certains résolveurs de FAI appliquent un plafond de TTL pour réduire la charge sur leurs serveurs. Un FAI qui traite des millions de requêtes par seconde peut décider de ne pas respecter un TTL de 60 secondes et de le traiter comme 300 secondes. Ce comportement est rare, non documenté, et contraire aux RFC, mais il existe.

Cache négatif. Le TTL s'applique aussi aux réponses NXDOMAIN (domaine inexistant) via le champ SOA minimum TTL (RFC 2308). Si vous créez un nouvel enregistrement pour un nom qui n'existait pas, le résolveur peut avoir mis en cache la réponse « n'existe pas » avec le TTL négatif de la zone SOA. Ce délai est souvent oublié lors des migrations.

Pour vérifier le TTL négatif de votre zone :

dig captaindns.com SOA +noall +answer

captaindns.com.    3600    IN    SOA    ns1.captaindns.com. admin.captaindns.com. 2026032601 7200 900 1209600 300

Le dernier champ (300) est le TTL négatif. Les réponses NXDOMAIN seront mises en cache pendant 300 secondes (5 minutes).

Les résolveurs DNS : tous différents face au cache

Le cache hiérarchique

La résolution DNS traverse plusieurs niveaux de cache avant d'atteindre le serveur faisant autorité. Chaque niveau peut retourner une réponse sans aller plus loin :

Niveau 1 : le cache applicatif. Les navigateurs et les applications maintiennent leur propre cache DNS. Chrome, par exemple, conserve les résolutions pendant 60 secondes par défaut. Ce cache est indépendant du système d'exploitation.

Niveau 2 : le stub resolver (cache OS). Le système d'exploitation maintient un cache DNS local. Sous Windows, le service « Client DNS » gère ce cache. Sous macOS, c'est mDNSResponder. Sous Linux avec systemd, c'est systemd-resolved. Ce cache respecte généralement le TTL retourné par le résolveur récursif.

Niveau 3 : le résolveur récursif. C'est le serveur DNS configuré dans votre connexion réseau (celui du FAI, Google 8.8.8.8, Cloudflare 1.1.1.1, etc.). C'est lui qui effectue la résolution complète en interrogeant la hiérarchie DNS et qui maintient le cache le plus conséquent. Le TTL à ce niveau détermine le délai perçu de « propagation ».

Niveau 4 : les relais DNS intermédiaires. Dans les réseaux d'entreprise, un serveur DNS interne (Active Directory, Pi-hole, dnsmasq) peut servir de relais vers le résolveur récursif. Ce relais ajoute un niveau de cache supplémentaire, avec ses propres règles de rétention.

Un changement DNS n'est pleinement visible pour un utilisateur que lorsque tous les niveaux de cache qu'il traverse ont expiré. Dans le pire cas (tous les caches viennent d'être remplis), le délai est celui du TTL le plus élevé dans la chaîne. En pratique, les caches applicatifs et OS ont des TTL courts (60 secondes ou moins), donc le goulot d'étranglement est presque toujours le résolveur récursif.

Pourquoi les résultats varient selon le résolveur ?

Quand vous testez la propagation DNS, vous pouvez obtenir des résultats différents selon le résolveur interrogé. C'est normal, et il y a trois raisons à cela.

Raison 1 : l'instant de mise en cache diffère. Google DNS a peut-être mis l'ancien enregistrement en cache il y a 2 minutes, alors que Cloudflare l'a fait il y a 55 minutes. Avec un TTL de 3 600 secondes, Google servira l'ancienne valeur pendant encore 58 minutes, tandis que Cloudflare la servira pendant encore 5 minutes. Même TTL, mais décalage temporel.

Raison 2 : l'infrastructure de cache est distribuée. Google DNS n'est pas un seul serveur. C'est un réseau de serveurs anycast répartis dans des centaines de datacenters. Chaque instance maintient son propre cache. Une requête depuis Paris touche un serveur Google différent de celui de Tokyo. Les deux peuvent avoir des valeurs de cache différentes. C'est pourquoi deux utilisateurs interrogeant « 8.8.8.8 » au même moment peuvent obtenir des réponses différentes.

Raison 3 : EDNS Client Subnet (ECS). Certains domaines utilisent des réponses géolocalisées via EDNS Client Subnet. Le serveur faisant autorité retourne des adresses IP différentes selon la localisation du client. Un utilisateur en France obtient l'IP du datacenter européen, un utilisateur au Japon obtient l'IP du datacenter asiatique. Ce n'est pas un problème de propagation : c'est le comportement attendu d'un CDN. Mais cela complique le diagnostic car les résolveurs ont des réponses légitimement différentes en cache.

Timeline montrant l'expiration du cache sur différents résolveurs publics : Google DNS, Cloudflare et Quad9 expirent le cache à des moments différents

Pour vérifier ce que chaque résolveur a en cache, interrogez-les directement :

dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer

Si les trois retournent la même IP avec des TTL restants différents, c'est la preuve que le changement est en cours et que les caches expirent à des moments différents.

Guide pratique : migration DNS sans surprise

La méthode qui suit élimine l'incertitude d'une migration DNS. Elle repose sur un principe simple : réduire le TTL avant le changement pour que le cache expire rapidement après la modification. C'est la technique standard utilisée par les SRE (Site Reliability Engineers) lors des migrations d'infrastructure.

Avant le changement : J-48

Étape 1 : vérifier le TTL actuel.

Interrogez le serveur faisant autorité pour connaître le TTL défini (pas le TTL restant dans un cache) :

dig captaindns.com A @ns1.captaindns.com +noall +answer

Si le TTL est de 86 400 secondes (24 heures), il faudra réduire et attendre que l'ancien cache expire.

Étape 2 : baisser le TTL à 300 secondes (5 minutes).

Dans l'interface de votre registrar ou votre gestionnaire de zone DNS, modifiez le TTL de l'enregistrement que vous comptez changer. Ne touchez pas encore la valeur de l'enregistrement. Seul le TTL change.

captaindns.com.    300    IN    A    76.76.21.21

Étape 3 : attendre l'expiration de l'ancien TTL.

C'est l'étape cruciale. Après avoir réduit le TTL à 300, vous devez attendre que l'ancien TTL expire partout. Si l'ancien TTL était de 86 400 secondes, attendez 24 heures. Si c'était 3 600 secondes, attendez 1 heure.

Pourquoi ? Parce que les résolveurs qui ont l'enregistrement en cache avec l'ancien TTL de 86 400 ne verront pas votre changement de TTL tant que leur cache n'aura pas expiré. Une fois l'ancien TTL expiré, tous les résolveurs interrogeront de nouveau le serveur faisant autorité et obtiendront l'enregistrement avec le nouveau TTL de 300 secondes.

C'est pour cette raison qu'il faut commencer 48 heures avant : dans le pire cas (TTL initial de 86 400), vous avez besoin de 24 heures pour la propagation du nouveau TTL, plus une marge de sécurité.

Vérifiez la progression en interrogeant plusieurs résolveurs :

dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer

Quand les trois retournent un TTL restant inférieur ou égal à 300, le nouveau TTL est en place.

Le jour du changement : J

Étape 4 : effectuer le changement DNS.

Modifiez la valeur de l'enregistrement chez votre registrar ou fournisseur DNS. Par exemple, pour une migration de serveur :

captaindns.com.    300    IN    A    185.199.108.153

Le TTL reste à 300 secondes. Le changement sera visible sur tous les résolveurs en 5 minutes maximum.

Étape 5 : vérifier la propagation.

Interrogez les principaux résolveurs publics pour confirmer que le changement est effectif :

dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer
dig captaindns.com A @208.67.222.222 +noall +answer

L'outil de test de propagation CaptainDNS effectue cette vérification automatiquement en interrogeant des résolveurs répartis sur plusieurs continents.

Étape 6 : valider le service.

Vérifiez que le service fonctionne correctement sur la nouvelle adresse. Testez les accès HTTP/HTTPS, les envois d'emails, les connexions API. Ne passez pas à l'étape suivante tant que tout n'est pas confirmé.

Après le changement : J+1

Étape 7 : remonter le TTL.

Une fois le changement confirmé et le service validé, remontez le TTL à une valeur standard. Un TTL de 3 600 secondes (1 heure) est un bon compromis entre réactivité et réduction de charge DNS :

captaindns.com.    3600    IN    A    185.199.108.153

Un TTL trop bas (60 secondes) en permanence surcharge les serveurs faisant autorité. Un TTL trop élevé (86 400 secondes) rend les migrations futures plus longues. Pour les enregistrements qui changent rarement (NS, MX), un TTL de 3 600 à 14 400 est raisonnable.

Étape 8 : surveiller pendant 24 à 48 heures.

Surveillez les métriques du service (temps de réponse, taux d'erreur, délivrabilité email) pendant les heures qui suivent la migration. Des résolveurs avec des comportements non standard peuvent tarder à mettre à jour leur cache. Un outil de supervision DNS résiliente permet de détecter ces anomalies.

Comment accélérer la « propagation » ?

Quand le changement est fait et que certains résolveurs servent encore l'ancienne valeur, il existe quelques actions concrètes pour réduire le délai. Aucune ne remplace la méthode de réduction de TTL décrite ci-dessus, mais elles sont utiles en complément.

Vider le cache DNS local

Le cache de votre machine locale peut contenir l'ancienne valeur. Le vider force votre système à interroger de nouveau le résolveur récursif.

Windows (PowerShell en administrateur) :

ipconfig /flushdns

macOS (Terminal) :

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Linux (systemd-resolved) :

sudo systemd-resolve --flush-caches

Chrome (barre d'adresse) :

chrome://net-internals/#dns

Cliquez sur « Clear host cache ». Chrome maintient son propre cache DNS indépendant de l'OS.

Demander une purge aux résolveurs publics

Certains résolveurs publics offrent une interface pour purger un enregistrement spécifique de leur cache. Ce n'est pas une garantie (l'enregistrement sera de nouveau mis en cache dès la prochaine requête), mais cela force une re-résolution immédiate.

Google Public DNS : rendez-vous sur la page Google Public DNS Flush Cache et saisissez le domaine et le type d'enregistrement à purger.

Cloudflare : rendez-vous sur la page Cloudflare Purge Cache et saisissez le domaine.

Ces outils purgent le cache d'un seul nœud (celui qui traite votre requête). Les résolveurs comme Google et Cloudflare utilisent l'anycast : le cache est distribué sur des centaines de serveurs. Purger depuis Paris ne purge pas le cache du serveur qui sert les utilisateurs de São Paulo.

Ce qui ne fonctionne PAS

Certaines « solutions » circulent sur les forums et les pages de support. Elles sont inefficaces, voire contre-productives.

Redémarrer le routeur. Le cache DNS du routeur domestique est souvent limité à quelques dizaines d'entrées et expire rapidement. Même si le redémarrage vide ce cache, le résolveur récursif du FAI (le vrai goulot d'étranglement) conserve l'ancienne valeur.

Changer de résolveur DNS sur le poste client. Passer de Google (8.8.8.8) à Cloudflare (1.1.1.1) peut donner l'impression que le changement est propagé, car Cloudflare n'a peut-être pas la même entrée en cache que Google. Mais cela ne résout rien pour les autres utilisateurs. C'est un biais d'observation, pas une solution.

Attendre « un peu plus ». Si le changement n'est pas visible après le délai correspondant au TTL, attendre davantage ne résoudra rien. Le problème est ailleurs : TTL négatif en cache, erreur dans la zone DNS, serveur faisant autorité mal configuré, ou résolveur qui ne respecte pas le TTL. Il faut diagnostiquer, pas patienter.

Cas d'usage spécifiques

Changement d'hébergeur (A / AAAA)

C'est le cas le plus fréquent : vous migrez un site web vers un nouveau serveur. L'enregistrement A (IPv4) ou AAAA (IPv6) change d'adresse IP.

Le plan standard fonctionne parfaitement ici. Réduisez le TTL 48 heures avant, changez l'IP, vérifiez. La particularité : si votre ancien et votre nouveau serveur sont configurés pour répondre au même nom de domaine, les utilisateurs qui obtiennent l'ancienne IP voient l'ancien serveur, ceux qui obtiennent la nouvelle voient le nouveau. Pendant la transition, les deux serveurs doivent fonctionner en parallèle.

Pour les migrations avec changement d'adresse IPv4 et IPv6 simultanément, n'oubliez pas de modifier les deux enregistrements. Un oubli sur l'enregistrement AAAA laisse les clients IPv6 pointer vers l'ancien serveur.

CNAME et alias

Les enregistrements CNAME ont leur propre TTL, mais le résolveur doit aussi résoudre la cible du CNAME. Le délai total est le maximum entre le TTL du CNAME et le TTL de l'enregistrement cible. Si votre CNAME a un TTL de 300 mais pointe vers un enregistrement A avec un TTL de 86 400, le changement de la valeur A prendra jusqu'à 24 heures même si le CNAME lui-même est résolu en 5 minutes.

Email : MX, SPF, DKIM, DMARC

Les enregistrements liés à l'email méritent une attention particulière car les conséquences d'une erreur sont plus graves que pour un site web. Un site inaccessible pendant 10 minutes est un désagrément. Des emails perdus pendant 10 minutes peuvent avoir des conséquences professionnelles sérieuses.

MX (Mail Exchanger). Les enregistrements MX ont souvent un TTL élevé (3 600 à 86 400). Lors d'une migration de fournisseur email, la réduction du TTL est obligatoire. Pendant la transition, les deux serveurs MX doivent accepter le courrier pour votre domaine. Configurez l'ancien fournisseur pour transférer les messages vers le nouveau si possible.

SPF (enregistrement TXT). Le changement d'un enregistrement SPF prend effet dès l'expiration du TTL du TXT. Le risque : si vous ajoutez un nouveau fournisseur d'envoi (comme un outil de marketing) sans mettre à jour le SPF, ses emails seront rejetés par les serveurs qui ont l'ancien SPF en cache. Solution : ajoutez le mécanisme SPF avant de commencer à envoyer via le nouveau fournisseur, et attendez l'expiration du TTL.

DKIM (enregistrement TXT sous _domainkey). La publication d'une nouvelle clé publique DKIM suit les mêmes règles de TTL. Attention lors d'une rotation de clé : l'ancienne clé doit rester publiée en DNS tant que des emails signés avec elle sont encore en transit (les queues email peuvent retenir des messages pendant plusieurs jours).

DMARC (enregistrement TXT sous _dmarc). Un changement de politique DMARC (passage de p=none à p=quarantine par exemple) prend effet progressivement au rythme de l'expiration des caches. Il est recommandé de passer par le mode p=quarantine avant p=reject pour limiter les faux positifs pendant la transition.

DNSSEC

L'activation ou la modification de DNSSEC ajoute une couche de complexité supplémentaire. Deux types d'enregistrements sont impliqués : les DNSKEY dans la zone DNS et l'enregistrement DS (Delegation Signer) chez le registrar.

L'enregistrement DS est publié dans la zone du TLD parent (par exemple, dans la zone .com pour un domaine .com). Sa mise à jour dépend du registrar et du registre TLD. Le délai est souvent plus long que pour un enregistrement standard car il implique une communication entre le registrar et le registre.

La règle lors de l'activation de DNSSEC : publier les DNSKEY en premier, attendre la propagation complète (au moins 2 fois le TTL), puis ajouter l'enregistrement DS. Si le DS est ajouté avant que les DNSKEY ne soient visibles partout, certains résolveurs validateurs retourneront SERVFAIL, rendant votre domaine inaccessible.

Changement de serveurs NS (délégation)

Changer les serveurs faisant autorité (enregistrements NS) est le cas le plus délicat. Les enregistrements NS au niveau du TLD ont leur propre TTL (souvent 48 heures pour .com). Le résolveur doit respecter ce TTL avant de réinterroger le registre TLD.

La procédure recommandée :

Reproduire la zone DNS complète sur les nouveaux serveurs NS
Réduire le TTL de tous les enregistrements importants à 300 secondes
Attendre l'expiration de l'ancien TTL
Modifier la délégation NS chez le registrar
Maintenir les anciens serveurs NS actifs pendant 48 à 72 heures (le temps que les caches NS expirent)
Vérifier que les deux jeux de serveurs NS retournent les mêmes réponses pendant toute la période de transition

Diagnostic : pourquoi mon changement DNS ne fonctionne pas ?

Quand le changement n'est toujours pas visible après le délai prévu, il faut diagnostiquer. Voici les causes les plus fréquentes, classées par probabilité.

Cause 1 : le changement n'a pas été enregistré

C'est la cause la plus courante. L'interface du registrar a affiché « enregistré » mais le serveur faisant autorité n'a pas encore la nouvelle valeur. Vérifiez directement :

dig captaindns.com A @ns1.captaindns.com +noall +answer

Si l'ancien enregistrement apparaît, le problème est chez le fournisseur DNS, pas dans la propagation.

Cause 2 : le cache négatif

Si vous avez créé un nouvel enregistrement (qui n'existait pas avant), le résolveur peut avoir une réponse NXDOMAIN en cache. Vérifiez le TTL négatif dans le SOA :

dig captaindns.com SOA +noall +answer

Le dernier champ du SOA est le TTL négatif. Attendez ce délai.

Cause 3 : le mauvais type d'enregistrement

Vous avez changé l'enregistrement A mais le DNS retourne un CNAME qui pointe vers l'ancien enregistrement. Ou vous avez modifié un TXT mais il y a deux enregistrements TXT et vous avez édité le mauvais. Vérifiez en demandant tous les types :

dig captaindns.com ANY @ns1.captaindns.com

Cause 4 : DNSSEC cassé

Si DNSSEC est actif et que la chaîne de confiance est rompue (enregistrement DS ne correspondant plus au DNSKEY), les résolveurs validateurs retournent SERVFAIL au lieu de la réponse. Testez avec et sans validation DNSSEC :

dig captaindns.com A @8.8.8.8 +dnssec
dig captaindns.com A @8.8.8.8 +cd

Le flag +cd (Checking Disabled) désactive la validation DNSSEC. Si la requête fonctionne avec +cd mais pas sans, le problème est DNSSEC.

Cause 5 : relais DNS d'entreprise avec cache agressif

Dans un réseau d'entreprise, un serveur DNS interne (Active Directory, Pi-hole) peut mettre en cache les réponses avec un TTL supérieur à celui retourné par le résolveur récursif. Contactez votre administrateur réseau pour vider le cache du serveur DNS interne.

Comprendre le rôle de la zone SOA

L'enregistrement SOA (Start of Authority) contient des paramètres qui influencent indirectement la « propagation ». Ses champs sont souvent négligés lors de la planification d'une migration.

dig captaindns.com SOA +noall +answer

captaindns.com. 3600 IN SOA ns1.captaindns.com. admin.captaindns.com. (
    2026032601 ; serial
    7200       ; refresh (2 heures)
    900        ; retry (15 minutes)
    1209600    ; expire (14 jours)
    300        ; minimum / negative TTL (5 minutes)
)

Serial : numéro de version de la zone. Les serveurs secondaires comparent ce numéro pour détecter les changements. Un serial qui n'est pas incrémenté après une modification empêche la synchronisation vers les serveurs secondaires.

Refresh : intervalle auquel les serveurs secondaires vérifient si la zone a changé. Un refresh de 7 200 secondes (2 heures) signifie que le serveur secondaire peut servir une zone obsolète pendant 2 heures. Ce paramètre impacte la cohérence entre serveurs faisant autorité, pas le cache des résolveurs récursifs.

Minimum (TTL négatif) : le TTL appliqué aux réponses NXDOMAIN. Si vous créez un nouvel enregistrement, les résolveurs qui ont une réponse NXDOMAIN en cache devront attendre ce délai. Valeur recommandée : 300 secondes (5 minutes).

Les résolveurs publics et leurs particularités

Chaque résolveur public a des comportements spécifiques qui influencent la perception de la propagation. Connaître ces spécificités aide au diagnostic. Un comparatif des résolveurs DNS publics permet d'aller plus loin sur ce sujet.

Google Public DNS (8.8.8.8 / 8.8.4.4)

TTL minimum : 30 secondes
Interface de purge disponible
Infrastructure anycast massive (centaines de PoP)
Supporte EDNS Client Subnet pour les réponses géolocalisées

Cloudflare (1.1.1.1 / 1.0.0.1)

TTL minimum : 30 secondes
Interface de purge disponible
Architecture anycast dans plus de 310 datacenters
Ne transmet pas le sous-réseau client par défaut (meilleure confidentialité)

Quad9 (9.9.9.9 / 149.112.112.112)

Filtrage malware intégré (peut bloquer certains domaines)
TTL minimum non documenté publiquement
Pas d'interface de purge publique
Validation DNSSEC activée par défaut

OpenDNS (208.67.222.222 / 208.67.220.220)

Filtrage configurable (catégories de contenu)
Cache pouvant être plus persistant que le TTL dans certains cas
Interface de purge via le tableau de bord

Résolveurs FAI

Comportement variable et souvent non documenté
Certains imposent des TTL minimum ou maximum
Cache parfois partagé entre millions d'abonnés (effet de mutualisation)
Rarement d'interface de purge

Plan d'action recommandé

Voici la procédure complète, résumée en 5 étapes. Imprimez-la ou enregistrez-la pour votre prochaine migration DNS.

Vérifier le TTL actuel : interrogez le serveur faisant autorité avec dig ou utilisez l'outil CaptainDNS pour obtenir le TTL de chaque enregistrement de votre zone.
Baisser le TTL 48 heures avant : réduisez à 300 secondes pour tous les enregistrements que vous comptez modifier. N'oubliez pas les enregistrements associés (AAAA si vous changez A, TXT si vous migrez le mail).
Effectuer le changement : modifiez les enregistrements DNS chez votre registrar ou fournisseur. Vérifiez immédiatement que le serveur faisant autorité retourne la nouvelle valeur.
Vérifier la propagation : testez depuis plusieurs résolveurs publics (Google, Cloudflare, Quad9, OpenDNS). Utilisez un outil de test de propagation pour une vue globale sur tous les continents.
Remonter le TTL : une fois le changement confirmé et le service validé, restaurez un TTL standard (3 600 secondes). Maintenez la surveillance pendant 24 heures.

FAQ

Combien de temps dure la propagation DNS ?

Le délai dépend uniquement du TTL (Time To Live) de l'enregistrement modifié. Avec un TTL de 300 secondes, le changement est visible partout en 5 minutes. Avec un TTL de 3 600 secondes, comptez 1 heure maximum. Avec un TTL de 86 400 secondes, le délai maximum est de 24 heures. Il n'y a aucune raison technique pour un délai de 48 heures. Le mythe des « 24 à 48 heures » vient d'une époque où les TTL par défaut étaient de 86 400 secondes et où les registres de TLD mettaient à jour leurs zones toutes les 12 heures.

Comment accélérer la propagation DNS ?

La méthode la plus efficace est de baisser le TTL à 300 secondes (5 minutes) au moins 48 heures avant le changement prévu. Une fois le TTL réduit propagé, tout changement ultérieur sera visible en 5 minutes. En complément, vous pouvez purger le cache de votre machine locale (ipconfig /flushdns sous Windows, sudo dscacheutil -flushcache sous macOS) et utiliser les interfaces de purge de Google Public DNS et Cloudflare pour forcer une re-résolution sur ces résolveurs spécifiques.

Pourquoi mon changement DNS ne fonctionne pas ?

Les causes les plus fréquentes sont, par ordre de probabilité : (1) le changement n'a pas été enregistré correctement chez le fournisseur DNS, (2) le cache négatif (NXDOMAIN) retient une ancienne réponse « n'existe pas », (3) le mauvais type d'enregistrement a été modifié, (4) la chaîne DNSSEC est cassée (l'enregistrement DS ne correspond plus au DNSKEY), (5) un relais DNS d'entreprise applique un cache agressif. Diagnostiquez en interrogeant directement le serveur faisant autorité avec dig captaindns.com A @ns1.captaindns.com pour vérifier que le changement est bien en place côté source.

C'est quoi le TTL DNS ?

Le TTL (Time To Live) est un champ numérique associé à chaque enregistrement DNS, exprimé en secondes. Il indique aux résolveurs récursifs combien de temps ils peuvent garder une réponse en cache avant de devoir interroger de nouveau le serveur faisant autorité. Par exemple, un TTL de 3 600 signifie que le résolveur utilisera la réponse en cache pendant 1 heure. Le TTL est défini par l'administrateur de la zone DNS, pas par le protocole. Chaque enregistrement peut avoir son propre TTL.

Faut-il attendre 24 à 48 heures après un changement DNS ?

Non. Ce délai ne s'impose que si le TTL de l'enregistrement modifié est de 86 400 secondes (24 heures), ce qui correspond au défaut historique de certains registrars. Avec un TTL de 3 600 secondes (1 heure, défaut courant en 2026), le délai maximum est de 1 heure. En préparant la migration (réduction du TTL à 300 secondes 48 heures avant), le changement est visible en 5 minutes. La recommandation « 24 à 48 heures » est un arrondi de précaution datant des années 2000 qui ne reflète plus la réalité technique actuelle.

Comment vider le cache DNS ?

Le cache DNS existe à plusieurs niveaux. Pour vider le cache de votre machine : sous Windows, exécutez ipconfig /flushdns dans PowerShell ; sous macOS, exécutez sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder dans le Terminal ; sous Linux avec systemd, exécutez sudo systemd-resolve --flush-caches. Pour Chrome, accédez à chrome://net-internals/#dns et cliquez « Clear host cache ». Pour vider le cache des résolveurs publics, utilisez les interfaces de Google Public DNS et Cloudflare 1.1.1.1. Le cache du résolveur de votre FAI n'est pas purgeable manuellement.

Pourquoi les résolveurs DNS donnent des résultats différents ?

Trois raisons expliquent ce comportement. Premièrement, chaque résolveur a mis l'enregistrement en cache à un moment différent, donc le TTL expire à des instants décalés. Deuxièmement, les grands résolveurs (Google, Cloudflare) utilisent des réseaux anycast avec des centaines de serveurs indépendants ; le serveur qui sert Paris n'a pas le même cache que celui qui sert Tokyo. Troisièmement, certains domaines utilisent EDNS Client Subnet (ECS) pour retourner des adresses IP géolocalisées, ce qui produit des réponses légitimement différentes selon la localisation du client.

Est-ce que changer de résolveur DNS accélère la propagation ?

Non, pas de manière fiable. Changer de résolveur sur votre poste (passer de 8.8.8.8 à 1.1.1.1 par exemple) peut donner l'impression que le changement est propagé si le nouveau résolveur n'a pas l'ancien enregistrement en cache. Mais cela n'accélère rien pour les autres utilisateurs. Le « délai de propagation » est lié au TTL du cache de chaque résolveur, et vous ne pouvez pas contrôler le cache du résolveur utilisé par vos visiteurs. La seule méthode fiable pour accélérer la propagation est de réduire le TTL avant le changement.

Comment vérifier si la propagation DNS est terminée ?

Interrogez au moins quatre résolveurs publics majeurs avec dig : Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) et OpenDNS (208.67.222.222). Si tous retournent la nouvelle valeur, la propagation est complète pour la grande majorité des utilisateurs. Pour une vérification exhaustive, utilisez un outil de test de propagation multi-résolveurs qui interroge des serveurs répartis sur plusieurs continents et affiche les résultats en temps réel. Tant qu'au moins un résolveur retourne l'ancienne valeur, la propagation n'est pas terminée.

Glossaire

TTL (Time To Live) : durée en secondes pendant laquelle un résolveur DNS peut garder un enregistrement en cache avant de le redemander au serveur faisant autorité. Défini par l'administrateur de zone.
Résolveur récursif : serveur DNS qui reçoit les requêtes des clients et effectue la résolution complète en interrogeant la hiérarchie DNS (racine, TLD, autoritaire). Exemples : Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1).
Serveur faisant autorité : serveur DNS qui détient les enregistrements originaux d'une zone DNS. C'est la source de vérité pour les enregistrements d'un domaine.
Cache DNS : mémoire temporaire où un résolveur stocke les réponses DNS déjà obtenues. Le cache réduit la charge sur les serveurs faisant autorité et accélère les réponses.
Zone DNS : ensemble d'enregistrements DNS pour un domaine et ses sous-domaines, hébergé sur un ou plusieurs serveurs faisant autorité.
NS record (Name Server) : enregistrement qui désigne les serveurs faisant autorité pour une zone DNS. Publié à la fois dans la zone parente (délégation) et dans la zone elle-même.
Stub resolver : composant du système d'exploitation qui transmet les requêtes DNS au résolveur récursif configuré. Il maintient un cache local minimal.
SOA (Start of Authority) : enregistrement obligatoire dans chaque zone DNS qui contient les métadonnées de la zone (serial, refresh, retry, expire, TTL négatif).
NXDOMAIN : réponse DNS indiquant que le nom de domaine demandé n'existe pas. Cette réponse est mise en cache selon le TTL négatif défini dans le SOA.
Anycast : technique de routage réseau où une même adresse IP est annoncée depuis plusieurs emplacements géographiques. Les résolveurs publics utilisent l'anycast pour diriger les requêtes vers le serveur le plus proche.

L'outil de test de propagation CaptainDNS interroge des résolveurs répartis sur tous les continents et affiche en temps réel l'état du cache pour chaque enregistrement. Utilisez-le pour confirmer qu'un changement DNS est visible partout avant de considérer la migration terminée.