Clear DNS : vider le cache DNS, poste par poste
« Clear DNS » désigne la purge du cache de résolution de noms, c'est-à-dire la suppression des correspondances nom/adresse IP mémorisées localement. L'opération prend une commande et une seconde, mais elle ne touche qu'une couche sur trois ou quatre, ce qui explique la plupart des flushs qui « ne servent à rien ».
Trois caches au moins, jamais un seul
Après un changement d'enregistrement A, la mauvaise réponse peut être stockée à quatre endroits indépendants : le service de résolution du système, le cache interne du navigateur, le résolveur récursif de votre FAI ou de votre fournisseur public, et parfois l'application elle-même. Chacun a son propre compteur de TTL. Vider le premier ne notifie aucun des autres.
C'est l'erreur numéro un en dépannage.
Un `ipconfig /flushdns` qui semble sans effet a presque toujours vidé quelque chose. Simplement pas la couche qui servait la réponse périmée. Avant de relancer la commande une troisième fois, identifiez laquelle des quatre répond encore, ce qui se fait en une requête `dig` ciblée sur chaque résolveur (voir plus bas).
- Cache système : Dnscache sous Windows, mDNSResponder sous macOS, systemd-resolved, dnsmasq ou nscd selon la distribution Linux
- Cache navigateur : Chrome, Edge et Firefox maintiennent le leur, avec des durées propres, et le contournent totalement si le DNS sécurisé (DoH) est activé
- Résolveur récursif : celui de votre box, ou 1.1.1.1, 8.8.8.8, 9.9.9.9. Vous ne pouvez pas le vider, seulement demander une purge d'une entrée précise
- Cache applicatif : la JVM, un conteneur, un pool de connexions ou nginx peuvent conserver une IP résolue au démarrage et l'oublier seulement au redémarrage du processus
Les commandes réelles, système par système
Sous Windows 10 et 11, `ipconfig /flushdns` exige une invite de commandes ou un PowerShell lancé en administrateur : sans élévation, la commande renvoie une erreur de privilèges au lieu de vider quoi que ce soit. L'équivalent PowerShell est `Clear-DnsClientCache`.
Sous macOS, une seule commande ne suffit plus depuis 10.10.4. Il faut enchaîner la purge du cache Directory Services et le rechargement du démon multicast : `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`. Aucun message ne confirme le succès, l'absence d'erreur est le seul retour.
Sous Linux, tout dépend de ce qui tourne réellement. Une machine Ubuntu récente utilise systemd-resolved, un Raspberry Pi avec Pi-hole utilise dnsmasq, un vieux serveur peut encore avoir nscd. Lancer la mauvaise commande retourne une erreur de service inconnu, ce qui est déjà une information.
| Système | Commande | Contrôle après coup |
|---|---|---|
| Windows 10 / 11 | ipconfig /flushdns (admin) | ipconfig /displaydns doit renvoyer une liste vide |
| macOS 11 à 15 | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder | aucun retour console, pas d'erreur = purgé |
| Linux systemd-resolved | resolvectl flush-caches | resolvectl statistics, ligne Current Cache Size à 0 |
| Linux dnsmasq / Pi-hole | sudo kill -HUP $(pidof dnsmasq) | le journal note le rechargement, le cache repart à zéro |
| Linux nscd | sudo nscd -i hosts | nscd -g affiche les compteurs du cache hosts |
Le cache du navigateur, celui qu’on oublie
Chrome ne consulte pas le cache système à chaque requête : il tient le sien, purgeable depuis `chrome://net-internals/#dns` avec le bouton Clear host cache. Edge expose la même page sous `edge://net-internals/#dns`, Firefox la sienne sous `about:networking#dns`.
Et ça ne suffit souvent pas.
Une connexion keep-alive déjà ouverte continue de parler à l'ancienne IP même après purge du cache de noms, parce que la socket est établie et qu'aucune nouvelle résolution n'est déclenchée. D'où le second bouton, Flush socket pools, dans `chrome://net-internals/#sockets`. Le réflexe complet en environnement de recette : vider le cache hôte, vider les pools de sockets, puis recharger avec Ctrl+Maj+R. Si le site est en HSTS et que vous testez en HTTP, ajoutez la suppression de la politique HSTS du domaine, toujours depuis net-internals.
Dernier piège : si le DNS sécurisé est actif dans les préférences du navigateur, la résolution part directement en HTTPS vers un résolveur DoH (RFC 8484, port 443) et ne passe plus jamais par le cache du système. Votre flush local devient purement décoratif.
Quand vider le cache ne changera rien
Le TTL est une durée décidée par la zone d'origine, pas par vous. Tant qu'il court chez le résolveur récursif que vous interrogez, celui-ci répondra l'ancienne valeur, quel que soit le nombre de purges effectuées sur votre poste. Les réponses négatives obéissent au même principe via le champ minimum de l'enregistrement SOA, mécanisme fixé par la RFC 2308 : un NXDOMAIN mémorisé peut survivre plusieurs minutes après la création effective de l'enregistrement.
Deux fournisseurs publics acceptent une purge à la demande, entrée par entrée : Google via dns.google/cache et Cloudflare via one.one.one.one/purge-cache. Vous saisissez le nom et le type, la purge est immédiate, mais elle ne vaut que pour ce résolveur.
Pour les délégations, c'est pire. Les serveurs de noms d'un domaine sont souvent servis par la zone TLD avec un TTL de 172 800 secondes, soit 48 heures. Changer de registrar ou de DNS puis vider son cache local n'accélère strictement rien. La seule action utile est préventive : abaisser le TTL des enregistrements concernés à 300 secondes 24 à 48 heures avant la bascule, faire la migration, puis remonter le TTL une fois la situation stable.
Vérifier que le flush a réellement eu lieu
Deux `dig` successifs suffisent. `dig @1.1.1.1 exemple.fr +noall +answer` affiche le TTL restant : s'il décroît d'un appel à l'autre, la réponse vient du cache du résolveur, si elle repart à sa valeur pleine, elle a été récupérée à la source.
Pour savoir si un résolveur donné détient encore une entrée sans provoquer sa mise en cache, `dig +norecurse @8.8.8.8 exemple.fr` : une réponse signifie qu'elle était déjà stockée, une réponse vide qu'elle ne l'est pas.
Reste le cas des applications, qui produit les pannes les plus longues à diagnostiquer. Un nginx dont le `proxy_pass` contient un nom de domaine en dur résout ce nom au démarrage et conserve l'adresse jusqu'au prochain reload, sauf si une directive `resolver` est combinée à une variable. Côté Java, la JVM applique par défaut un cache positif de l'ordre de 30 secondes et un cache négatif de 10 secondes (`networkaddress.cache.ttl` et `networkaddress.cache.negative.ttl`), valeurs qui passent à « pour toujours » lorsqu'un gestionnaire de sécurité est installé. Sur ces couches, la seule purge fiable est le redémarrage du processus.
Testez vos connaissances
Quelle commande vide le cache DNS d'un système Linux utilisant systemd-resolved ?
Score : 0 sur 3
Questions fréquentes
Comment vider le cache DNS sous Windows sans passer par l’invite de commandes ?
Un redémarrage du service DNS Client fait le même travail : `Restart-Service Dnscache` en PowerShell administrateur, ou via services.msc. La cmdlet `Clear-DnsClientCache` reste plus rapide et n'interrompt pas les résolutions en cours.
Faut-il redémarrer la machine après un clear DNS ?
Non. La purge est effective immédiatement. Le redémarrage n'a d'intérêt que pour les processus qui gardent leur propre cache en mémoire, typiquement une JVM, un service applicatif ou un conteneur lancé avant le changement.
Vider le cache DNS change-t-il mon adresse IP publique ?
Aucun rapport. Le cache DNS mémorise des correspondances nom vers adresse pour les sites que vous consultez, il ne contient pas votre propre adresse et n'agit pas sur le bail DHCP ni sur l'attribution de votre FAI.
Pourquoi mon site pointe encore vers l’ancien serveur après le flush ?
Parce que la réponse périmée vient d'ailleurs. Testez l'enregistrement directement auprès du serveur faisant autorité avec `dig @ns1.exemple.fr exemple.fr`, puis auprès de votre résolveur : si les deux diffèrent, c'est le TTL du résolveur qui court, et il faut l'attendre ou demander une purge ciblée.
Vider le cache DNS accélère-t-il la navigation ?
L'inverse, à court terme. Chaque nom devra être résolu à nouveau, ce qui ajoute une latence de quelques dizaines de millisecondes à la première visite. Le flush se justifie pour corriger une résolution fausse ou périmée, pas pour optimiser.