Purge DNS : ce que vide vraiment un flush de cache
Purger le DNS efface les correspondances nom vers adresse IP mémorisées par votre navigateur et votre système, pas celles du résolveur récursif que vous interrogez ni celles des serveurs faisant autorité. Une seule commande suffit selon la plateforme, mais elle ne raccourcit jamais le TTL qui continue de courir ailleurs sur le réseau.
Quatre caches, une commande n’en vide que deux
Un même nom de domaine peut vous être servi depuis quatre endroits distincts : le cache interne du navigateur, le cache du système, le cache du résolveur récursif que vous interrogez (celui de votre box, de votre FAI, ou 8.8.8.8), et enfin le serveur faisant autorité pour la zone. La purge lancée depuis votre poste n'agit que sur les deux premiers niveaux, et chacun des deux réclame sa propre commande.
Le reste continue de tourner sans vous.
Cas typique : vous repointez un enregistrement A, vous lancez ipconfig /flushdns, vous rechargez la page, l'ancienne IP revient. La commande a pourtant fonctionné. Elle a vidé un cache qui n'était pas celui qui vous répondait, puisque le résolveur récursif conserve son ancienne réponse jusqu'à expiration du TTL reçu au moment de la mise en cache, souvent 3600 ou 86400 secondes.
- Navigateur : Chrome expose Clear host cache sur chrome://net-internals/#dns, Firefox un bouton équivalent sur about:networking#dns
- Système : client DNS de Windows, systemd-resolved, nscd ou dnsmasq, selon ce qui tourne réellement sur la machine
- Résolveur récursif : hors de votre contrôle, sauf formulaire public exposé par l'opérateur
- Serveurs faisant autorité : aucun cache à purger, ils servent le fichier de zone tel qu'il est chargé
- Si DoH est actif dans le navigateur, celui-ci résout lui-même sur le port 443 et court-circuite le cache système : la purge Windows n'a alors aucun effet sur ces requêtes
Les commandes qui marchent, système par système
Sur Windows, ouvrez l'invite de commandes en administrateur. La commande ipconfig /flushdns répond Successfully flushed the DNS Resolver Cache, ou son équivalent français sur une installation localisée. Sans élévation, elle peut échouer sur une erreur de privilèges au lieu d'afficher la confirmation. Pour contrôler avant et après, ipconfig /displaydns liste les entrées avec leur TTL restant, qui décompte seconde par seconde.
Détail qui piège : les lignes du fichier hosts réapparaissent immédiatement dans displaydns après la purge. C:\Windows\System32\drivers\etc\hosts est rechargé, pas vidé. Si vous y avez laissé une entrée de test, aucune purge ne vous en débarrassera.
Sur macOS, les deux commandes vont ensemble et dans cet ordre. dscacheutil vide le cache du Directory Service, killall -HUP mDNSResponder relance le démon qui porte réellement le cache DNS ; n'en lancer qu'une laisse la moitié du travail en plan.
Sur Linux, il n'existe pas de commande universelle, ce qui explique la moitié des mauvaises réponses trouvées en ligne. Regardez d'abord /etc/resolv.conf : s'il pointe sur 127.0.0.53, vous êtes sur systemd-resolved et resolvectl flush-caches suffit, resolvectl statistics confirmant la remise à zéro des compteurs. S'il pointe sur l'IP de votre routeur, le cache utile est dans le routeur et aucune commande locale ne le videra. Et beaucoup de serveurs n'ont tout simplement aucun cache local : chaque requête part directement vers le résolveur configuré, il n'y a donc rien à purger.
| Système | Commande | Vérification |
|---|---|---|
| Windows 10 et 11 | ipconfig /flushdns (invite élevée) | ipconfig /displaydns |
| macOS | sudo dscacheutil -flushcache puis sudo killall -HUP mDNSResponder | Console.app, filtre mDNSResponder |
| Linux systemd-resolved | resolvectl flush-caches | resolvectl statistics |
| Linux dnsmasq | sudo systemctl restart dnsmasq | journalctl -u dnsmasq |
| Chrome | chrome://net-internals/#dns, Clear host cache | onglet Sockets, Flush socket pools |
Purger chez un résolveur public : ce qui est réellement possible
Google et Cloudflare exposent tous les deux un formulaire de purge. Chez Google, sur developers.google.com/speed/public-dns/cache, vous saisissez un nom et un type d'enregistrement, un par un. Cloudflare propose la même chose sur one.one.one.one/purge-cache/.
L'effet s'arrête à l'opérateur concerné.
Purger 8.8.8.8 ne change rien pour un abonné qui interroge le résolveur de son FAI, et sur un site grand public une bonne part du trafic passe justement par ces résolveurs-là. Vous n'avez aucun levier dessus. C'est la raison pour laquelle un TTL se prépare avant la bascule au lieu de se rattraper après.
Pour savoir si une réponse sort d'un cache, comparez le TTL renvoyé à celui publié dans la zone. La commande dig @8.8.8.8 exemple.fr A +noall +answer, relancée dix secondes plus tard, montre un TTL qui décroît quand la réponse est en cache, et qui repart à sa valeur pleine après expiration ou purge. L'option +norecurse va plus loin : elle interdit au résolveur d'aller chercher la réponse, il ne répond donc que s'il la détient déjà.
Quand la purge ne change rien
La connexion déjà ouverte, d'abord. Le navigateur conserve des sockets en keep-alive vers l'ancienne adresse et continue de les réutiliser une fois le cache DNS vidé. Chrome permet de forcer la fermeture depuis chrome://net-internals/#sockets, bouton Flush socket pools ; à défaut, fermez complètement le navigateur, tous les onglets compris.
Le NXDOMAIN mémorisé, ensuite. Si vous avez testé un sous-domaine avant de le créer, la réponse négative est conservée selon la règle de la RFC 2308, qui borne cette durée par le champ MINIMUM de l'enregistrement SOA et recommande de rester sous trois heures. Un SOA laissé à 86400 sur ce champ vous fait attendre une journée pour un nom qui existe pourtant déjà.
Le cache du CDN, qui n'a aucun rapport. Purger le DNS n'invalide pas un seul objet chez un fournisseur de diffusion : le nom résout toujours vers le même point de présence, lequel vous ressert le même HTML. La purge de contenu se pilote dans l'interface du CDN, c'est une opération séparée avec ses propres règles.
Le mode serve-stale de la RFC 8767, enfin, autorise un résolveur à servir des données expirées quand les serveurs faisant autorité ne répondent plus. Purger chez cet opérateur peut alors vous rendre la même réponse périmée, faute pour lui de pouvoir en obtenir une fraîche.
Baisser le TTL avant la bascule, l’étape qui évite la purge
La purge est un correctif d'urgence. Le vrai levier reste le TTL, décidé avant la migration.
Comptez à rebours. Si votre enregistrement A est publié avec un TTL de 86400, passez-le à 300 au moins 24 heures avant la bascule, le temps que tous les résolveurs aient rechargé la valeur courte. Le basculement se joue alors sur une fenêtre de cinq minutes au lieu d'une journée entière, et vous remontez le TTL à 3600 une fois la situation stable, pour ne pas encaisser une requête toutes les cinq minutes et par résolveur.
Le changement de serveurs de noms obéit à d'autres délais : la délégation NS servie par les serveurs de .com porte un TTL de 172800 secondes, soit 48 heures, et cette valeur ne se pilote pas depuis votre zone.
Gardez l'ancien serveur en ligne pendant toute cette fenêtre.
Contrôle avant bascule, avec une adresse prise dans la plage de documentation 203.0.113.0/24 définie par la RFC 5737 : dig +nocmd exemple.fr A +noall +answer renvoie une ligne du type exemple.fr. 300 IN A 203.0.113.10. Tant qu'un résolveur tiers vous affiche encore 86400 dans la colonne TTL, la bascule est prématurée et aucune purge locale ne compensera l'attente.
Testez vos connaissances
Quelle commande vide le cache DNS sur une distribution Linux qui utilise systemd-resolved ?
Score : 0 sur 3
Questions fréquentes
ipconfig /flushdns demande-t-il les droits administrateur ?
Sur Windows 10 et 11, lancez-la depuis une invite de commandes ou un PowerShell ouvert en administrateur. Depuis une console utilisateur standard, elle peut renvoyer une erreur d'élévation au lieu du message de confirmation. Le service concerné s'appelle Dnscache : le redémarrer produit le même résultat, mais la commande reste plus rapide.
Combien de temps dure la propagation DNS ?
Le terme est trompeur, rien ne se propage. Chaque résolveur conserve l'ancienne réponse jusqu'à expiration du TTL reçu au moment de la mise en cache. Le pire cas est donc l'ancien TTL, pas une durée universelle. Les 48 heures souvent citées correspondent au TTL de la délégation NS chez des TLD comme .com et ne concernent qu'un changement de serveurs de noms.
La purge DNS accélère-t-elle la navigation ?
Non, elle la ralentit brièvement. Chaque nom doit être résolu à nouveau, ce qui ajoute un aller-retour vers le résolveur sur les premières requêtes. L'intérêt de la purge est la fraîcheur des réponses, pas la vitesse.
Comment vérifier qu’un nom est encore en cache chez un résolveur public ?
Utilisez dig @1.1.1.1 exemple.fr A +norecurse. Le résolveur ne fait alors aucune résolution récursive et ne répond qu'à partir de son cache. Un TTL inférieur à celui publié dans la zone signale une entrée en cours de décompte.
Purger le DNS efface-t-il l’historique de navigation ?
Non. Le cache DNS ne contient que des correspondances entre noms et adresses IP, sans URL, sans cookie, sans contenu de page. Il révèle en revanche la liste des domaines contactés récemment, lisible avec ipconfig /displaydns, ce qui en fait une trace locale à part entière.