Tutoriel Linux

DNS cache under Linux: how to clear it without restarting the entire machine

Débutant5 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.

You change a DNS entry, restart a service, test a connection, and your Linux machine continues to resolve the old result. In this case, restarting the entire server is rarely the right solution. The local DNS cache can often be flushed cleanly, without shutting down the machine.

The important point is to know who keeps the cacheDepending on the distribution, you might come across systemd-resolvedNetworkManager with a DNS plugin, nscd, A dnsmasq local, or simply no truly active local DNS cache.

I suggest a simple method: identify the resolver, clear the appropriate cache, then check that you are not confusing local cache, public DNS and application cache.

Tux cleans a Linux DNS cache containing servers and abstract network symbols.
Before restarting a server, identify the local DNS resolver and clear only the relevant cache.

Start by identifying the resolver used

Before running random commands, check how your machine resolves names. The first check is done with /etc/resolv.conf :

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

If the file points to a systemd path like /run/systemd/resolve/stub-resolv.confYou have a good chance of using systemd-resolvedConfirm with:

systemctl is-active systemd-resolved
resolvectl status

On some machines, NetworkManager also manages DNS. Check its status:

systemctl is-active NetworkManager
nmcli general status

If you are administering an older server, also check if nscd Or dnsmasq turns:

systemctl is-active nscd
systemctl is-active dnsmasq

This step avoids a common mistake: clearing the cache of systemd-resolved while the machine is not using this service, then believe that Linux is ignoring your command.

Clear the systemd-resolved cache with resolvectl

On recent distributions, the cleanest command is usually resolvectlStart by looking at the solver’s statistics:

resolvectl statistics

You can then clear the local DNS cache:

sudo resolvectl flush-caches

The documentation of resolvectl clearly indicates that flush-caches This clears the DNS records that the service maintains locally. This is not a network reboot, and that’s precisely the point of the command.

To verify properly, you can reset the counters, run a resolution, and then review the statistics:

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

If resolvectl does not exist, try the old name on some distributions:

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

I still prefer resolvectl when it is available. This is the current order around systemd-resolved.

If NetworkManager manages the DNS

On a Linux machine or server with NetworkManager, the cache may be linked to the DNS plugin used. If you have modified a DNS configuration managed by NetworkManager, first request a DNS reload:

sudo nmcli general reload dns-full

The reference nmcli describe dns-full such as restarting the DNS plugin. This is useful, for example, if NetworkManager uses a plugin dnsmasq with files under /etc/NetworkManager/dnsmasq.d/.

Next, verify that the resolution is indeed going through the expected servers:

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

Avoid blindly restarting NetworkManager on a remote machine. systemctl restart NetworkManager This can interrupt the network connection. If you are connected via SSH, keep a backup console or an already open session. The same logic applies as for a system service: check before acting, especially on a server.

If you need to check active services before making any changes to the network, the article on systemctl and the list of Linux services This step is completed successfully.

Clear nscd or dnsmasq if they are the ones hiding it.

nscd It is not used solely for DNS. It can cache several NSS databases, including hostsIf the service is active, you can only invalidate the host cache:

sudo nscd -i hosts

The page nscd(8) This invalidation option is documented. If you have any doubt about the service status:

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

For dnsmasqThe case depends on your configuration. On a server that launches a real service dnsmasqRestarting the service clears its cache:

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

If dnsmasq is only used as a plugin by NetworkManager, use the other method instead nmcli general reload dns-fullRestarting the wrong service may not change anything, or it may just waste your time on the wrong floor.

Verify that the local cache was indeed the problem.

After clearing the cache, test the resolution on the system side:

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

If you have dig Or drillAlso compare with a public resolver. On Debian or Ubuntu, dig usually comes from the package dnsutils :

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

If the public resolver is still returning the old IP address, your Linux machine is probably not the cause. DNS TTL, an ISP’s cache, or incomplete propagation could still be involved. Clearing the local cache doesn’t force the entire internet to forget an old response.

Also consider applications. A browser, proxy, runtime, or container may maintain its own cache or resolution. If a curl If the shell is working but the browser continues to fail, the problem is no longer necessarily at the level of systemd-resolved.

Read the logs if the DNS resolution remains strange.

When the resolution remains inconsistent, check the logs of the service actually being used. For systemd-resolved :

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

For NetworkManager:

journalctl -u NetworkManager -b --no-pager

Also check the overall network status. A bad route, an inaccessible DNS server, or an overly strict firewall can give the impression of a blocked cache:

ip route
resolvectl dns
resolvectl domain
ss -lntup

If you want to check what’s really listening on the machine, you can supplement it with the guide on open ports under Linux using ss and netstatFor a problem after a change of address, see the article on static IP address under Debian can also help to properly rebuild the network foundations.

My clean sequence before restarting anything

On a typical Linux machine, I usually follow this sequence:

  • read /etc/resolv.conf and identify the resolver;
  • check systemd-resolvedNetworkManager, nscd Or dnsmasq ;
  • clear only the relevant cache;
  • test with getent hosts, resolvectl query Or dig ;
  • read the logs before restarting a network service;
  • Restart NetworkManager or the entire machine only as a last resort.

If you are on a remote server, be even more careful. Clearing a local DNS cache is a simple operation. Restarting a network service is much more complex. Keep a session open and check the logs with journalctlThen validate the resolution from the shell before touching anything else.

sudo apt update && sudo apt upgrade