Comment vider le cache DNS dans Windows, macOS et Chrome

Vider votre cache DNS force votre système d’exploitation ou votre navigateur à supprimer les enregistrements DNS stockés localement et à récupérer de nouveaux mappages depuis les serveurs de noms faisant autorité. Cette seule opération résout un nombre surprenant de pannes de connectivité — des erreurs ERR_NAME_NOT_RESOLVED aux enregistrements IP obsolètes laissés après une migration de serveur.

Qu’est-ce qu’un cache DNS ? Il s’agit d’une base de données temporaire et locale maintenue par votre système d’exploitation (et séparément par certains navigateurs) qui stocke les résultats des recherches DNS précédentes. Chaque fois que vous résolvez un nom d’hôte comme example.com, l’adresse IP résultante est stockée avec un compteur TTL (Time To Live). Jusqu’à l’expiration de ce TTL, votre système ignore entièrement le résolveur en amont et utilise l’enregistrement mis en cache — ce qui est rapide, mais devient un problème dès que cet enregistrement devient obsolète, est empoisonné ou pointe vers un serveur désaffecté.

Pourquoi le cache DNS devient-il un problème

Comprendre les modes de défaillance permet de comprendre pourquoi le vidage est parfois le seul correctif approprié :

• Migration de serveur ou changement d’IP : Lorsqu’un site migre vers une nouvelle infrastructure, ses enregistrements DNS sont mis à jour avec un nouvel enregistrement A ou AAAA. Si votre cache local contient toujours l’ancienne IP, chaque requête est envoyée au mauvais hôte — entraînant souvent un délai d’expiration de connexion ou une erreur de non-concordance de certificat TLS.
• Empoisonnement du cache DNS : Les logiciels malveillants et les attaques de type man-in-the-middle peuvent injecter des enregistrements frauduleux dans votre cache local, redirigeant silencieusement le trafic vers des serveurs contrôlés par des attaquants. Vider le cache supprime immédiatement les entrées empoisonnées.
• Mise en cache négative : Une recherche DNS échouée (réponse NXDOMAIN) est également mise en cache. Si un domaine était temporairement inaccessible et que le résultat négatif a été mis en cache, votre système refusera de le résoudre à nouveau jusqu’à l’expiration du TTL négatif — même après que le domaine soit de nouveau en ligne.
• Conflits DNS split-horizon : Les développeurs travaillant avec des remplacements /etc/hosts locaux ou des résolveurs assignés par VPN rencontrent fréquemment des entrées de cache obsolètes qui remplacent leur routage prévu.
• Artefacts après déconnexion VPN : Les entrées DNS résiduelles d’une session VPN peuvent persister après la déconnexion, provoquant des fuites DNS ou des pannes de routage sur le réseau local.

Comment vider le cache DNS sous Windows

La procédure est identique sous Windows 7, 8, 10 et 11. La seule différence notable est de savoir si vous préférez l’Invite de commandes ou PowerShell.

Méthode 1 : Invite de commandes (ipconfig /flushdns)

1. Appuyez sur Win + R, tapez cmd, puis appuyez sur Ctrl + Shift + Enter pour lancer l’Invite de commandes avec les privilèges administrateur. Vous pouvez également rechercher Invite de commandes dans le menu Démarrer, faire un clic droit dessus et sélectionner Exécuter en tant qu’administrateur.
2. Exécutez la commande de vidage :

ipconfig /flushdns

1. Un vidage réussi renvoie :

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Si vous obtenez une erreur à la place, assurez-vous d’avoir ouvert l’invite avec des privilèges élevés. Les sessions utilisateur standard n’ont pas d’accès en écriture au cache du service DNS Client.

Méthode 2 : Windows PowerShell

PowerShell expose une cmdlet dédiée qui interagit directement avec le service DNS Client plutôt que de passer par l’interface ipconfig héritée.

1. Appuyez sur Win + X et sélectionnez Windows PowerShell (Admin) ou Terminal (Admin) sous Windows 11.
2. Exécutez :

Clear-DnsClientCache

Il n’y a pas de message de confirmation en cas de succès — la commande se termine silencieusement. Pour vérifier que le cache est vide, exécutez Get-DnsClientCache immédiatement après ; cela ne devrait retourner aucun résultat.

Méthode 3 : Redémarrage du service DNS Client

Dans les rares cas où les commandes ci-dessus échouent — généralement en raison d’un état corrompu du service DNS Client — le redémarrage du service lui-même vide le cache comme effet secondaire :

Stop-Service -Name Dnscache -Force
Start-Service -Name Dnscache

Mise en garde importante : Sur certaines configurations Windows, le service DNS Client est défini comme une dépendance pour d’autres services réseau. Son arrêt peut brièvement interrompre la connectivité réseau. Ne l’exécutez pas sur un serveur de production sans fenêtre de maintenance.

Affichage du cache DNS actuel (Windows)

Avant de vider le cache, il est souvent utile d’inspecter ce qui est mis en cache pour confirmer si un enregistrement obsolète est réellement la cause de votre problème :

Get-DnsClientCache

Cela affiche toutes les entrées mises en cache avec leur TTL, leur type d’enregistrement et leurs données résolues — bien plus utile pour le diagnostic que de vider le cache aveuglément.

Comment vider le cache DNS sur macOS

macOS utilise mDNSResponder comme démon de service DNS sur toutes les versions modernes. Le mécanisme de vidage est resté cohérent depuis macOS Sierra, mais les versions plus anciennes nécessitaient des commandes différentes.

macOS Ventura, Monterey, Big Sur, Catalina, Mojave, High Sierra, Sierra (10.12 et versions ultérieures)

1. Ouvrez Terminal via Applications > Utilities > Terminal ou appuyez sur Cmd + Space et tapez Terminal.
2. Exécutez :

sudo killall -HUP mDNSResponder

1. Entrez votre mot de passe administrateur lorsque vous y êtes invité. Le champ de mot de passe n’affichera pas les caractères — c’est un comportement attendu. Appuyez sur Enter pour confirmer.

Il n’y a pas de message de succès. Le signal -HUP demande à mDNSResponder de recharger sa configuration et de purger son cache sans redémarrage complet.

macOS El Capitan et Yosemite (10.11 / 10.10)

El Capitan utilise la même commande mDNSResponder que ci-dessus. Yosemite a brièvement remplacé mDNSResponder par discoveryd, nécessitant une approche différente :

sudo discoveryutil udnsflushcaches

macOS Mavericks, Mountain Lion et Lion (10.9 et versions antérieures)

sudo killall -HUP mDNSResponder

Vidage des couches de cache DNS supplémentaires sur macOS

macOS maintient plus d’un cache DNS. Pour un vidage complet — particulièrement pertinent lors du débogage de problèmes DNS split ou mDNS — exécutez les trois commandes en séquence :

sudo killall -HUP mDNSResponder
sudo killall mDNSResponderHelper
sudo dscacheutil -flushcache

dscacheutil -flushcache vide le cache des services d’annuaire, qui stocke des données supplémentaires de résolution de noms utilisées par les processus au niveau du système. L’omettre peut laisser des entrées résiduelles que mDNSResponder seul ne supprime pas.

Comment vider le cache DNS dans Google Chrome

Chrome maintient son propre cache DNS interne qui fonctionne de manière totalement indépendante du résolveur au niveau du système d’exploitation. Il s’agit d’une décision architecturale délibérée — la pile réseau de Chrome (construite sur la bibliothèque net:: de Chromium) pré-résout les domaines qu’il prédit que vous allez visiter et met ces résultats en cache en cours de processus. Cela signifie que vous pouvez vider le cache DNS du système d’exploitation et Chrome continuera à servir des enregistrements obsolètes depuis son propre stockage.

Étape par étape : Vider le cache DNS de Chrome

1. Ouvrez Google Chrome.
2. Dans la barre d’adresse, naviguez vers :

chrome://net-internals/#dns

1. Cliquez sur le bouton Clear host cache. Cela purge immédiatement toutes les entrées DNS contenues dans le cache en cours de processus de Chrome.

Réinitialisation des pools de sockets de Chrome

Les entrées du cache DNS et les connexions TCP/TLS ouvertes sont des préoccupations distinctes. Si vous avez vidé le cache DNS mais que Chrome achemine toujours le trafic via une ancienne connexion (par exemple, après un changement d’IP de serveur), vous devez également vider le pool de sockets :

1. Naviguez vers :

chrome://net-internals/#sockets

1. Cliquez sur Flush socket pools.

Cela ferme toutes les connexions keep-alive inactives et actives, forçant Chrome à rétablir de nouvelles connexions TCP en utilisant les adresses IP nouvellement résolues.

Redémarrage de Chrome après le vidage

Fermez complètement toutes les fenêtres Chrome et rouvrez le navigateur. Sur macOS, assurez-vous que Chrome ne fonctionne pas encore en arrière-plan via le Dock — faites un clic droit sur l’icône et sélectionnez Quitter plutôt que de simplement fermer la fenêtre.

Comparaison du cache DNS : niveau OS vs. niveau navigateur

Commandes de vidage par plateforme en un coup d’œil

Linux est inclus ici car les administrateurs gérant des environnements VPS Hosting ont fréquemment besoin de vider les caches DNS à la fois sur leur poste de travail local et sur le serveur distant simultanément lors de la propagation des modifications DNS.

Erreurs courantes que le vidage du cache DNS résout

• ERR_NAME_NOT_RESOLVED — Chrome ne peut pas résoudre le nom d’hôte. Il s’agit presque toujours d’un problème DNS ; videz les caches du système d’exploitation et de Chrome.
• DNS_PROBE_FINISHED_NXDOMAIN — Le résolveur a renvoyé une réponse de domaine inexistant. Peut être une entrée de cache négatif obsolète.
• ERR_CONNECTION_TIMED_OUT après une migration de serveur — L’ancienne IP est toujours en cache. Videz le cache du système d’exploitation et vérifiez avec nslookup ou dig que la nouvelle IP est renvoyée.
• Erreurs de non-concordance de certificat TLS/SSL — Si l’IP mise en cache pointe vers un serveur différent de celui qui détient le certificat correct, vous obtiendrez une erreur de non-concordance de nom de certificat. Cela est courant lorsqu’un domaine change de fournisseur d’hébergement. Si vous gérez une infrastructure SSL, assurez-vous que vos Certificats SSL sont provisionnés sur la bonne origine avant l’expiration du TTL DNS.
• Erreurs 404 intermittentes après une migration CMS — Le site se charge, mais les ressources ou les pages renvoient 404. Souvent causé par le CDN ou le proxy inverse qui résout toujours vers l’ancienne origine. Videz les caches à chaque couche.

Propagation DNS vs. cache local : une distinction essentielle

Une idée reçue courante est que vider le cache DNS local rendra immédiatement visible un enregistrement DNS nouvellement publié. Ce n’est pas le cas — si le résolveur récursif en amont (le serveur DNS de votre FAI ou un résolveur public comme 8.8.8.8) a également mis en cache l’ancien enregistrement, vous continuerez à recevoir l’ancienne IP jusqu’à l’expiration du cache de ce résolveur.

Le flux de diagnostic correct est :

1. Vérifiez l’enregistrement faisant autorité directement en utilisant dig @8.8.8.8 example.com A ou nslookup example.com 1.1.1.1.
2. Si l’enregistrement faisant autorité est correct mais que votre résolution locale est incorrecte, videz le cache du système d’exploitation local.
3. Si l’enregistrement faisant autorité lui-même est toujours incorrect, le problème se situe au niveau du registraire DNS ou du panneau de contrôle d’hébergement — pas dans le cache local.

Lors de la gestion du DNS pour des domaines hébergés sur des Serveurs Dédiés, définissez toujours un TTL bas (300 secondes) au moins 24 heures avant une migration planifiée. Cela minimise la fenêtre de propagation et réduit l’impact des entrées de cache obsolètes sur Internet.

Implications de sécurité de la gestion du cache DNS

L’empoisonnement du cache DNS (également connu sous le nom de DNS spoofing) est une classe d’attaque où un adversaire injecte des enregistrements A ou CNAME malveillants dans le cache d’un résolveur, redirigeant les utilisateurs vers des serveurs frauduleux. Bien que DNSSEC fournisse une validation cryptographique au niveau du protocole, l’hygiène du cache local reste une mesure pratique de première intervention.

Si vous suspectez que votre cache DNS a été empoisonné :

1. Videz immédiatement le cache local en utilisant la commande appropriée pour votre système d’exploitation.
2. Passez à un résolveur validant DNSSEC tel que Cloudflare (1.1.1.1) ou Google (8.8.8.8).
3. Inspectez les processus en cours d’exécution pour détecter les logiciels malveillants susceptibles de modifier le fichier hosts (C:WindowsSystem32driversetchosts sous Windows, /etc/hosts sur les systèmes Unix).
4. Vérifiez les paramètres DNS de votre routeur — les attaquants qui compromettent un routeur peuvent rediriger toutes les requêtes DNS sur le réseau quel que soit l’état du cache local.

Pour les entreprises gérant leur propre infrastructure de messagerie, l’intégrité DNS est particulièrement critique. Des enregistrements DNS mal configurés ou empoisonnés affectent directement la validation SPF, DKIM et DMARC. Si vous utilisez des services d’Hébergement Email, vérifiez que les enregistrements MX, SPF et DKIM se résolvent correctement après tout changement DNS.

Automatisation des vidages du cache DNS

Pour les développeurs et les administrateurs système qui travaillent régulièrement avec des modifications DNS — notamment lors de la configuration de Panneaux de contrôle VPS, des changements d’environnement de staging ou des migrations de domaines — l’automatisation du vidage supprime entièrement l’étape manuelle.

Tâche planifiée Windows (PowerShell) :

$action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-Command Clear-DnsClientCache"
$trigger = New-ScheduledTaskTrigger -Daily -At "03:00AM"
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "FlushDNSCache" -RunLevel Highest

plist launchd macOS (vidage quotidien à 3h du matin) :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.local.flushdns</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/bash</string>
    <string>-c</string>
    <string>killall -HUP mDNSResponder</string>
  </array>
  <key>StartCalendarInterval</key>
  <dict>
    <key>Hour</key>
    <integer>3</integer>
    <key>Minute</key>
    <integer>0</integer>
  </dict>
</dict>
</plist>

Enregistrez ce fichier dans ~/Library/LaunchAgents/com.local.flushdns.plist et chargez-le avec launchctl load ~/Library/LaunchAgents/com.local.flushdns.plist.

Les vidages automatisés sont particulièrement utiles dans les pipelines CI/CD où les enregistrements DNS sont mis à jour de manière programmatique dans le cadre d’un flux de déploiement, et où les agents de build doivent résoudre les nouveaux enregistrements immédiatement après l’application de la modification.

Matrice de décision technique : quand vider et où

Liste de contrôle pratique avant et après le vidage

• Confirmez que la modification DNS s’est propagée aux serveurs faisant autorité en utilisant dig ou un outil en ligne comme whatsmydns.net avant de vider localement.
• Notez le TTL actuel de l’enregistrement que vous dépannez — s’il est de 86400 secondes (24 heures), vider localement ne vous aide que vous ; les autres utilisateurs verront toujours l’ancien enregistrement pendant jusqu’à 24 heures.
• Sous Windows, exécutez ipconfig /displaydns avant de vider pour capturer un instantané de l’état actuel du cache à des fins de diagnostic.
• Après le vidage, utilisez nslookup example.com ou ping example.com pour confirmer que la nouvelle IP est renvoyée avant d’ouvrir le navigateur.
• Si vous travaillez dans un environnement d’Hébergement Web Mutualisé, n’oubliez pas que les serveurs de noms du fournisseur d’hébergement mettent également les enregistrements en cache — contactez le support si la propagation semble bloquée au niveau du serveur.
• Pour Chrome spécifiquement, après avoir vidé le cache DNS, videz également le pool de sockets et effectuez un rechargement forcé (Ctrl + Shift + R sous Windows/Linux, Cmd + Shift + R sur macOS) pour contourner également le cache HTTP du navigateur.
• Documentez le vidage dans un journal des modifications s’il est effectué dans un environnement de production — les modifications DNS et les vidages de cache sont fréquemment négligés lors du diagnostic de problèmes post-déploiement des jours plus tard.

FAQ

Le vidage du cache DNS affecte-t-il la vitesse de navigation ?

Temporairement, oui. Après un vidage, votre système doit effectuer de nouvelles recherches DNS pour chaque nom d’hôte qu’il contacte, ce qui ajoute une légère surcharge de latence (généralement 20–100ms par recherche) jusqu’à ce que le cache se repeuple. Pour la plupart des utilisateurs, cela est imperceptible. Le cache se reconstruit automatiquement en quelques minutes de navigation normale.

Le vidage du cache DNS me déconnectera-t-il des sites web ?

Non. Les entrées du cache DNS sont entièrement distinctes des cookies du navigateur, des jetons de session et de l’état d’authentification. Le vidage DNS ne touche à aucun de ces éléments.

En quoi ipconfig /flushdns diffère-t-il de Clear-DnsClientCache ?

Les deux commandes demandent au service DNS Client de Windows de purger son cache. ipconfig /flushdns est une interface héritée qui communique avec le service via l’utilitaire ipconfig ; Clear-DnsClientCache est une cmdlet PowerShell native qui utilise directement l’interface WMI/CIM. Le résultat final est identique, mais Clear-DnsClientCache est scriptable et retourne des objets structurés, ce qui le rend préférable dans les contextes d’automatisation.

Pourquoi Chrome affiche-t-il toujours l’ancien site web après que j’ai vidé le cache DNS du système d’exploitation ?

Chrome maintient son propre cache DNS en cours de processus qui n’est pas affecté par les vidages au niveau du système d’exploitation. Vous devez vider séparément le cache de Chrome via chrome://net-internals/#dns. De plus, si l’ancienne connexion TCP est toujours active dans le pool de sockets de Chrome, vous devez également vider les pools de sockets via chrome://net-internals/#sockets.

À quelle fréquence dois-je vider mon cache DNS ?

Il n’y a pas de calendrier universel. Videz-le de manière réactive — lorsque vous rencontrez des erreurs liées au DNS, après une migration de serveur ou de domaine, après un incident de sécurité suspecté, ou lors du passage entre des configurations réseau VPN et non-VPN. Les vidages planifiés de routine ne sont justifiés que dans les environnements de développement ou de staging où les enregistrements DNS changent fréquemment.