« Propagation » : pourquoi l'un le voit déjà et l'autre pas

Module 6: Temps, cache et transfert de domaine · Temps de lecture : 8 minutes

Objectif pédagogique : après cette leçon, vous pourrez expliquer pourquoi une modification DNS n'est pas visible partout en même temps, estimer la durée nécessaire et résoudre le problème si vous êtes le seul à encore voir l'ancienne situation.

Notions clés : « propagation », cache, cache négatif (NXDOMAIN), minimum SOA, TTL de délégation, changement de serveur de noms, vider le cache

Un malentendu en un mot

Vous avez modifié un enregistrement. Votre collègue voit déjà le nouveau site, vous voyez encore l'ancien. Sur internet, on lit alors : « attendez, le DNS doit encore se propager. » Le mot propagation (diffusion) donne l'impression que votre modification se répand comme une vague sur internet, de serveur en serveur.

Ce n'est pas ainsi que cela fonctionne. Votre modification est immédiatement présente sur les serveurs de noms faisant autorité de votre domaine (ou en quelques minutes, si votre prestataire DNS synchronise plusieurs serveurs de noms). Rien n'est diffusé. Ce que vous observez, c'est l'expiration des caches : chaque résolveur donne l'ancienne réponse jusqu'à ce que le TTL dans son cache soit écoulé (leçon 6.1). Comme chaque résolveur a commencé à compter à un moment différent, l'un voit la modification plus tôt que l'autre.

« Propagation » signifie donc en réalité : attendre que tous les caches se soient vidés. Cette compréhension vous aide, car vous savez désormais précisément ce que vous attendez et combien de temps cela peut durer au maximum.

Combien de temps cela prend-il ?

Cela dépend de ce que vous modifiez.

Enregistrements existants

Ici, c'est simple : l'ancien TTL constitue le maximum. Si l'enregistrement avait un TTL de 3600, tout le monde verra la nouvelle réponse au plus tard une heure après votre modification. Si, après plus d'une heure, quelqu'un voit encore l'ancienne réponse, le problème se situe ailleurs (voir plus loin).

Nouveaux enregistrements et le cache négatif

Un nouvel enregistrement fonctionne souvent immédiatement, sauf si quelqu'un a déjà demandé le nom alors qu'il n'existait pas encore. Le résolveur a alors reçu la réponse NXDOMAIN (« ce nom n'existe pas ») ou « ce nom existe, mais n'a pas d'enregistrement de ce type ». Ce « non » est également mémorisé. On appelle cela le cache négatif.

La durée pendant laquelle un « non » est conservé ne figure pas dans un enregistrement qui n'existe pas. Elle provient de l'enregistrement SOA de la zone : selon la RFC 2308, il s'agit du plus petit de deux nombres, le TTL de l'enregistrement SOA lui-même et le dernier champ de l'enregistrement SOA (le « minimum »). Un exemple :

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; numéro de série
                             14400      ; refresh
                             3600       ; retry
                             1209600    ; expire
                             300 )      ; minimum

Ici, un « non » est mémorisé pendant 300 secondes maximum (le plus petit entre 3600 et 300). Pour certaines zones, cela peut être une heure ou plus.

D'où la règle d'or : n'ouvrez pas un nouveau sous-domaine dans votre navigateur avant de l'avoir créé. Votre ordinateur et votre résolveur retiennent alors qu'il n'existe pas, et vous êtes le seul à devoir attendre.

Changer de serveurs de noms

Lors d'un changement de serveurs de noms, vous attendez autre chose : les enregistrements NS chez le registre de votre extension. Ces enregistrements indiquent aux résolveurs où se trouvent les serveurs de noms de votre domaine (leçon 2.1), et ils sont également mémorisés. Chaque registre choisit son propre TTL pour cela. Mesuré en novembre 2026 :

À cela s'ajoute le fait qu'un registre ne publie parfois pas immédiatement votre modification, et que les serveurs de noms de votre ancien prestataire continuent souvent, entre-temps, à répondre avec l'ancienne zone. Comptez donc, lors d'un changement de serveurs de noms, sur quelques heures, et pour .com, jusqu'à deux jours au maximum. Veillez donc à ce que les deux prestataires disposent, pendant le changement, des mêmes enregistrements corrects (leçon 6.3).

Êtes-vous le seul à encore voir l'ancienne version ?

Un vérificateur en ligne affiche-t-il déjà la nouvelle réponse chez presque tous les résolveurs, mais pas chez vous ? Alors l'ancienne réponse se trouve près de chez vous. Parcourez ces étapes, de la plus rapide à la plus approfondie :

1. Fenêtre privée ou autre navigateur. Votre navigateur conserve des réponses DNS et des pages.
2. Téléphone via 4G ou 5G, wifi désactivé. Vous utilisez alors le résolveur de votre opérateur mobile au lieu de celui de votre réseau domestique.

3. Vider le cache de votre ordinateur.

   • Windows (Invite de commandes) : ipconfig /flushdns
   • macOS (Terminal) : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux avec systemd-resolved : resolvectl flush-caches
4. Redémarrer le routeur. De nombreux routeurs fonctionnent comme de petits résolveurs avec leur propre cache.
5. Vérifier le fichier hosts. Avez-vous déjà testé un nouveau serveur en indiquant l'adresse dans votre fichier hosts (C:\Windows\System32\drivers\etc\hosts ou /etc/hosts) ? Cette ligne prend le pas sur le DNS. Supprimez-la. C'est souvent oublié.
6. Vérifier directement à la source. Interrogez l'enregistrement auprès du serveur de noms faisant autorité (dig A example.com @ns1.hosting.example). Si l'ancienne réponse s'y trouve encore, la modification n'a pas été correctement enregistrée ou vous l'avez effectuée au mauvais endroit.

Toujours rien après le délai d'attente ?

Si le TTL est déjà largement écoulé et que même les outils en ligne affichent l'ancienne réponse, attendre ne sert à rien. Autre chose se passe alors. Les trois causes les plus fréquentes :

• Modification au mauvais endroit. Votre domaine utilise les serveurs de noms d'un autre prestataire (par exemple Cloudflare ou un constructeur de site), et vous avez modifié les enregistrements chez votre hébergeur. Vérifiez quels serveurs de noms votre domaine utilise (leçon 2.1) et effectuez la modification à cet endroit.
• Faute de frappe ou point manquant. mail.example.com sans point devient, dans de nombreux panneaux, mail.example.com.example.com (leçon 2.2).
• Les serveurs de noms ne sont pas d'accord entre eux. Un domaine possède au moins deux serveurs de noms. S'ils ne se synchronisent pas correctement, l'un donne la nouvelle réponse et l'autre l'ancienne. Comparez le numéro de série SOA sur chaque serveur de noms : il doit être identique.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

En pratique : à quoi cela ressemble dans un panneau

Si vous souhaitez voir ce que répondent les résolveurs à différents endroits du monde, utilisez un vérificateur DNS en ligne qui interroge un résolveur par pays (par exemple dnschecker.org). Dans le panneau d'exemple Mon WebOké, la carte Domaine / Santé e-mail vérifie les serveurs de noms et enregistrements de votre domaine auprès des serveurs de noms faisant autorité, et le diagnostic DNS compare les numéros de série des serveurs de noms. D'autres prestataires proposent souvent un contrôle similaire dans leur panneau ; sinon, dig et les outils en ligne de la leçon 8.3 donnent le même résultat.

Résumé

• Rien n'est « diffusé » : vous attendez que les caches expirent.
• Un enregistrement modifié est visible partout au plus tard après l'ancien TTL ; un nouvel enregistrement l'est généralement immédiatement, sauf si quelqu'un a déjà demandé le nom auparavant (cache négatif, déterminé par l'enregistrement SOA).
• Un changement de serveurs de noms dépend du TTL chez le registre : une heure pour .nl, deux jours pour .com.
• Êtes-vous le seul à encore voir l'ancienne version ? Fenêtre privée, 4G, vider le cache, redémarrer le routeur et vérifier le fichier hosts.
• Toujours l'ancienne réponse au niveau du serveur de noms faisant autorité ? Attendre ne sert alors à rien : cherchez l'erreur.

Quiz

Exercice

Exercice Z6.2 : TTL de délégation et cache négatif. Deux questions, toutes deux répondables avec dig ou un outil dig en ligne :

1. Combien de secondes les résolveurs mémorisent-ils, selon le registre .com, les serveurs de noms de google.com ? Interrogez un serveur .com : dig NS google.com @a.gtld-servers.net et observez le TTL dans la section AUTHORITY.
2. Combien de secondes un résolveur mémorise-t-il qu'un nom sous sidn.nl (le site de SIDN, le registre du .nl aux Pays-Bas) n'existe pas ? Interrogez l'enregistrement SOA de sidn.nl auprès de ns1.sidn.nl et appliquez la règle de cette leçon (le plus petit entre le TTL du SOA et le minimum du SOA).

Pour aller plus loin

Les étapes de ces articles concernent les panneaux de WebOké ; dans d'autres panneaux, le fonctionnement est similaire.

• Combien de temps dure une modification de nameserver ou de DNS, et que faire si vous ne la voyez pas ?
• Le site web ou l'e-mail ne fonctionne pas après un déménagement ou une modification DNS : vérifiez votre domaine
• Guide DirectAdmin 5.11: Quand une modification prend-elle effet ? Délai d'attente et TTL
• Créer un sous-domaine, et que faire si cela ne fonctionne pas
• Comment tester mon domaine avant son transfert ? (localhost)
• Guide WebOké 5.17: Santé du domaine et de l'e-mail : vérifier et corriger