Tutoriel Linux

Cache DNS sous Linux : comment le vider sans redémarrer toute la machine

Débutant6 min de lecture
À retenirLinux n'est pas réservé aux experts. Le bon point de départ : une distribution accessible, une sauvegarde propre et quelques commandes comprises.

Vous changez une entrée DNS, vous relancez un service, vous testez une connexion, et votre machine Linux continue de résoudre l’ancien résultat. Dans ce cas, redémarrer tout le serveur est rarement la bonne réponse. Le cache DNS local peut souvent être vidé proprement, sans couper la machine.

Le point important, c’est de savoir qui garde le cache. Selon la distribution, vous pouvez tomber sur systemd-resolved, NetworkManager avec un plugin DNS, nscd, un dnsmasq local, ou simplement aucun cache DNS local vraiment actif.

Je vous propose une méthode simple : identifier le résolveur, vider le cache adapté, puis vérifier que vous ne confondez pas cache local, DNS public et cache applicatif.

Tux nettoie un cache DNS Linux avec des serveurs et des symboles réseau abstraits
Avant de redémarrer un serveur, identifiez le résolveur DNS local et videz uniquement le cache concerné.

Commencez par identifier le résolveur utilisé

Avant de lancer des commandes au hasard, regardez comment votre machine résout les noms. La première vérification se fait avec /etc/resolv.conf :

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Si le fichier pointe vers un chemin systemd comme /run/systemd/resolve/stub-resolv.conf, vous avez de bonnes chances d’utiliser systemd-resolved. Confirmez avec :

systemctl is-active systemd-resolved
resolvectl status

Sur certaines machines, NetworkManager pilote aussi le DNS. Vérifiez son état :

systemctl is-active NetworkManager
nmcli general status

Si vous administrez un serveur plus ancien, regardez aussi si nscd ou dnsmasq tourne :

systemctl is-active nscd
systemctl is-active dnsmasq

Cette étape évite une erreur classique : vider le cache de systemd-resolved alors que la machine n’utilise pas ce service, puis croire que Linux ignore votre commande.

Vider le cache systemd-resolved avec resolvectl

Sur les distributions récentes, la commande la plus propre est généralement resolvectl. Commencez par regarder les statistiques du résolveur :

resolvectl statistics

Vous pouvez ensuite vider le cache DNS local :

sudo resolvectl flush-caches

La documentation de resolvectl indique bien que flush-caches vide les enregistrements DNS que le service maintient localement. Ce n’est pas un redémarrage réseau, et c’est justement l’intérêt de la commande.

Pour vérifier proprement, vous pouvez remettre les compteurs à zéro, lancer une résolution, puis relire les statistiques :

sudo resolvectl reset-statistics
resolvectl query www.linuxencaja.net
resolvectl statistics

Si resolvectl n’existe pas, essayez l’ancien nom sur certaines distributions :

systemd-resolve --statistics
sudo systemd-resolve --flush-caches

Je préfère tout de même resolvectl quand il est disponible. C’est la commande actuelle autour de systemd-resolved.

Si NetworkManager gère le DNS

Sur un poste Linux ou un serveur avec NetworkManager, le cache peut être lié au plugin DNS utilisé. Si vous avez modifié une configuration DNS gérée par NetworkManager, commencez par demander un rechargement DNS :

sudo nmcli general reload dns-full

La référence nmcli décrit dns-full comme un redémarrage du plugin DNS. C’est utile, par exemple, si NetworkManager utilise un plugin dnsmasq avec des fichiers sous /etc/NetworkManager/dnsmasq.d/.

Vérifiez ensuite que la résolution passe bien par les serveurs attendus :

nmcli device show | grep -E 'DNS|DOMAIN'
resolvectl status

Évitez de redémarrer NetworkManager à l’aveugle sur une machine distante. Un systemctl restart NetworkManager peut interrompre la connexion réseau. Si vous êtes connecté en SSH, gardez une console de secours ou une session déjà ouverte. Même logique que pour un service système : vérifiez avant d’agir, surtout sur un serveur.

Si vous devez justement vérifier les services actifs avant de toucher au réseau, l’article sur systemctl et la liste des services Linux complète bien cette étape.

Vider nscd ou dnsmasq si ce sont eux qui cachent

nscd ne sert pas uniquement au DNS. Il peut cacher plusieurs bases NSS, dont hosts. Si le service est actif, vous pouvez invalider uniquement le cache des hôtes :

sudo nscd -i hosts

La page nscd(8) documente cette option d’invalidation. Si vous avez un doute sur l’état du service :

systemctl status nscd --no-pager
journalctl -u nscd -b --no-pager

Pour dnsmasq, le cas dépend de votre configuration. Sur un serveur qui lance un vrai service dnsmasq, le redémarrage du service vide son cache :

sudo systemctl restart dnsmasq
systemctl status dnsmasq --no-pager

Si dnsmasq est seulement utilisé comme plugin par NetworkManager, passez plutôt par nmcli general reload dns-full. Redémarrer le mauvais service peut ne rien changer, ou vous faire perdre du temps sur le mauvais étage.

Vérifier que le cache local était bien le problème

Après avoir vidé le cache, testez la résolution côté système :

getent hosts www.linuxencaja.net
resolvectl query www.linuxencaja.net

Si vous avez dig ou drill, comparez aussi avec un résolveur public. Sur Debian ou Ubuntu, dig vient généralement du paquet dnsutils :

dig www.linuxencaja.net
dig @1.1.1.1 www.linuxencaja.net

Si le résolveur public renvoie encore l’ancienne IP, votre machine Linux n’est probablement pas responsable. Le TTL DNS, le cache d’un fournisseur, ou une propagation incomplète peuvent encore jouer. Vider le cache local ne force pas tout Internet à oublier une ancienne réponse.

Pensez aussi aux applications. Un navigateur, un proxy, un runtime ou un conteneur peut garder son propre cache ou sa propre résolution. Si un curl côté shell fonctionne mais que le navigateur continue d’échouer, le problème n’est plus forcément au niveau de systemd-resolved.

Les logs à lire si la résolution DNS reste étrange

Quand la résolution reste incohérente, regardez les logs du service réellement utilisé. Pour systemd-resolved :

journalctl -u systemd-resolved -b --no-pager

Pour NetworkManager :

journalctl -u NetworkManager -b --no-pager

Regardez aussi l’état réseau général. Une mauvaise route, un serveur DNS inaccessible ou un pare-feu trop strict peut donner l’impression d’un cache bloqué :

ip route
resolvectl dns
resolvectl domain
ss -lntup

Si vous voulez vérifier ce qui écoute vraiment sur la machine, vous pouvez compléter avec le guide sur les ports ouverts sous Linux avec ss et netstat. Pour un problème après changement d’adresse, l’article sur l’IP fixe sous Debian peut aussi aider à reprendre les bases réseau proprement.

Ma séquence propre avant de redémarrer quoi que ce soit

Sur une machine Linux classique, je fais généralement cette séquence :

  • lire /etc/resolv.conf et identifier le résolveur ;
  • vérifier systemd-resolved, NetworkManager, nscd ou dnsmasq ;
  • vider uniquement le cache concerné ;
  • tester avec getent hosts, resolvectl query ou dig ;
  • lire les logs avant de redémarrer un service réseau ;
  • ne redémarrer NetworkManager ou la machine complète qu’en dernier recours.

Si vous êtes sur un serveur distant, soyez encore plus prudent. Vider un cache DNS local est une opération légère. Redémarrer un service réseau l’est beaucoup moins. Gardez une session ouverte, vérifiez les logs avec journalctl, puis validez la résolution depuis le shell avant de toucher au reste.

sudo apt update && sudo apt upgrade