Vider le cache DNS dans vos réseaux : méthodes concrètes pour les administrateurs informatiques

Le cache DNS garde en mémoire les correspondances entre noms de domaine et adresses IP. Ça accélère les résolutions suivantes, mais dès qu’une IP change – migration de serveur, mise à jour d’enregistrement A dans votre zone Active Directory, basculement de VM – les postes clients continuent de renvoyer l’ancienne valeur. Vider le cache DNS force alors une requête fraîche vers les serveurs récursifs ou faisant autorité. Sur le terrain, c’est l’une des premières manips qu’on fait quand un service interne devient inaccessible alors que le ping IP fonctionne nickel.

Qu’est-ce que le cache DNS et d’où viennent les problèmes

Le résolveur stub sur chaque poste Windows, macOS ou Linux stocke les réponses DNS pendant la durée de vie indiquée par le TTL. Même chose sur vos serveurs DNS récursifs internes ou chez le FAI. Quand le TTL est long (plusieurs heures), ou quand vous venez de modifier un enregistrement, le cache local ou intermédiaire garde l’ancienne IP. Résultat : erreurs NXDOMAIN, pages qui ne chargent plus, ou redirection vers une ancienne version de l’application. Le cache du navigateur ajoute parfois une couche supplémentaire, surtout sur Chrome et Edge qui font leur propre mise en cache agressive.

Le point c’est que vider le cache DNS n’efface rien de définitif. C’est réversible en deux secondes et ça n’impacte pas la stabilité du réseau. Mais ça reste une opération de dépannage, pas une routine quotidienne.

Situations concrètes où vous allez devoir vider le cache DNS

Imaginons que vous migrez votre CRM interne vers un nouveau serveur avec une IP différente. Les utilisateurs sur site continuent de tomber sur l’ancienne machine pendant des heures, voire jusqu’à la fin du TTL. Ou alors un enregistrement SRV dans votre forêt Active Directory a été mis à jour et les postes ne le voient pas tout de suite. Autre cas classique : après un changement chez un hébergeur externe, la propagation DNS prend 24-48 h côté autorités, mais vos postes locaux bloquent sur l’ancienne IP jusqu’à ce que vous interveniez.

Parfois aussi c’est un problème de cache corrompu ou empoisonné (rare aujourd’hui grâce à DNSSEC, mais ça arrive encore). Ou simplement des entrées négatives qui persistent et empêchent la résolution d’un nom qui vient d’être créé.

La procédure standard pour vider le cache DNS sur Windows

Ouvrez l’invite de commandes en tant qu’administrateur. Tapez ipconfig /flushdns et validez. Le message « Le cache du résolveur DNS a été vidé avec succès » s’affiche. C’est la commande la plus utilisée sur les postes clients et les serveurs Windows eux-mêmes.

Pour vérifier avant et après, utilisez ipconfig /displaydns. Vous verrez la liste des entrées en cache avec leur TTL restant. Si vous préférez PowerShell (plus pratique pour les scripts), Clear-DnsClientCache fait exactement la même chose.

Dans un contexte plus large, quand le problème persiste, enchaînez souvent avec ipconfig /release, ipconfig /renew, ipconfig /registerdns et netsh winsock reset. Redémarrez ensuite la machine. Ça réinitialise toute la pile réseau et résout pas mal de cas tordus.

Vider le cache DNS sur macOS et Linux : les commandes à connaître

Sur macOS, ouvrez le Terminal et lancez sudo dscacheutil -flushcache ; sudo killall -HUP mDNSResponder. Entrez votre mot de passe admin quand demandé. Sur les versions récentes (Ventura, Sonoma, Sequoia), cette combinaison reste fiable. Pour les anciennes versions le killall seul suffisait parfois.

Sous Linux ça dépend du résolveur en place. La plupart des distributions actuelles utilisent systemd-resolved. Tapez sudo resolvectl flush-caches (ou sudo systemd-resolve --flush-caches sur les versions plus anciennes). Pour vérifier : resolvectl statistics. Si vous tournez encore sur dnsmasq ou nscd, un simple sudo systemctl restart dnsmasq ou sudo systemctl restart nscd fait l’affaire. Pour un serveur BIND, sudo rndc flush puis sudo rndc reload vide le cache sans redémarrer le démon.

Le truc c’est d’identifier d’abord quel service écoute sur le port 53 avec sudo lsof -i :53 -S avant de lancer la mauvaise commande.

Ne pas oublier le cache des navigateurs

Parfois le flush système ne suffit pas parce que Chrome, Edge ou Firefox gardent leur propre cache DNS. Dans Chrome ou Edge, tapez chrome://net-internals/#dns dans la barre d’adresse, cliquez sur « Clear host cache », puis allez dans l’onglet Sockets et faites « Flush socket pools ». Sur Firefox, direction about:networking#dns, bouton « Vider le cache DNS » puis actualisez.

Safari passe par le menu Développement > Vider les caches après avoir activé le menu développeur dans les préférences. Ces étapes règlent souvent les cas où un site s’affiche encore avec l’ancien contenu même après le flush système.

Cas des serveurs DNS en entreprise

Sur un contrôleur de domaine ou un serveur DNS Windows, vider le cache client avec ipconfig /flushdns ne suffit pas toujours. Il faut aussi vider le cache du serveur lui-même avec dnscmd /clearcache ou, mieux, via PowerShell : Clear-DnsServerCache -ComputerName "votre-serveur-dns" -Force. Ça supprime les enregistrements mis en cache par le rôle DNS Server sans toucher aux zones intégrées Active Directory.

Sur un serveur Linux faisant autorité avec BIND, rndc flush reste la méthode propre. Dans les deux cas, après le flush, testez avec nslookup ou dig depuis un poste client pour confirmer que la nouvelle IP remonte bien.

Quand le flush ne suffit pas : étapes de dépannage avancées

Si après toutes ces manips le problème persiste, regardez le fichier hosts local (C:\Windows\System32\drivers\etc\hosts ou /etc/hosts). Une entrée statique peut surcharger le DNS. Vérifiez aussi les paramètres DNS du poste ou de la carte réseau : parfois on a forcé un serveur DNS qui n’est plus à jour.

Passez temporairement sur un résolveur public comme 1.1.1.1 de Cloudflare ou 8.8.8.8 de Google. C’est rapide, ça contourne souvent les caches ISP et ça permet de confirmer que le souci vient bien du cache local ou du résolveur de l’entreprise. Le résolveur 1.1.1.1 est d’ailleurs apprécié en entreprise pour sa politique de confidentialité et sa rapidité.

Sur les postes mobiles, le mode Avion activé/désactivé vide le cache DNS sans rien casser. La réinitialisation complète des paramètres réseau marche aussi mais elle efface les Wi-Fi enregistrés, donc à réserver aux cas désespérés.

Bonnes pratiques pour une gestion proactive dans vos infrastructures

Dans un parc de plusieurs dizaines ou centaines de postes, vider le cache DNS à la main sur chaque machine n’est pas viable. Script PowerShell ou déploiement via RMM (Datto, NinjaOne, etc.) pour pousser Clear-DnsClientCache ou ipconfig /flushdns à distance après une modification DNS. Mettez en place une procédure documentée : avant toute migration ou changement d’IP, prévenir les équipes et prévoir un flush coordonné.

Surveillez les logs DNS sur vos serveurs pour repérer les requêtes répétées vers des noms qui devraient être résolus rapidement. Évitez de vider systématiquement les caches serveurs (ça augmente la charge sur les autorités en amont). Privilégiez plutôt un TTL raisonnable sur vos zones internes et activez DNSSEC là où c’est possible pour limiter les risques d’empoisonnement.

Au bout du compte, vider le cache DNS reste un outil simple et puissant, à condition de l’utiliser au bon moment et de savoir ce qu’il y a derrière. Testez toujours après intervention avec nslookup ou un simple ping du nom de domaine concerné. Ça évite les allers-retours inutiles avec les utilisateurs.