How to flush DNS cache in Linux

Flushing the local DNS cache helps after an IP cutover, a resolver-side fix, or a stale cached answer keeps one Linux host pointed at the wrong address. Clearing the cached records forces the next lookup to ask the configured resolver again instead of reusing older data until its TTL expires.

On many current Linux distributions, systemd-resolved provides the local caching resolver and may expose a stub listener on 127.0.0.53 through /etc/resolv.conf. The resolvectl flush-caches command clears the resource records held locally, and resolvectl query shows whether the next lookup came from the network or from cache.

This workflow applies only when systemd-resolved is the active local resolver, even if upstream DNS servers come from NetworkManager, systemd-networkd, or DHCP. Hosts that rely on dnsmasq, nscd, or another resolver need that service's own cache-clear command, while browser and application-specific DNS caches remain separate from the system cache.

1. Check that systemd-resolved is the active local resolver on the host.

   $ resolvectl status
   Global
            Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
     resolv.conf mode: stub
   
   Link 2 (eth0)
       Current Scopes: DNS
            Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
   Current DNS Server: 192.0.2.53
          DNS Servers: 192.0.2.53 192.0.2.54
           DNS Domain: example.net

   A successful resolvectl status output with active DNS scopes and current DNS servers confirms that systemd-resolved is handling lookups. If the command is unavailable or shows no active DNS link, the host is likely using another resolver service.

   Related: How to manage a Linux service with systemctl

2. Flush the local DNS cache.

   $ resolvectl flush-caches

   The command normally returns no output when the cache flush succeeds. systemd-resolved also clears its cache automatically when network configuration changes, so manual flushes are mainly useful before an immediate retest or while debugging stale answers.

3. Query a hostname once so the next lookup is forced back to the upstream resolver.

   $ resolvectl query example.com
   example.com: 172.66.147.243                                 -- link: enp0s5
                104.20.23.154                                  -- link: enp0s5
                2606:4700:10::6814:179a                        -- link: enp0s5
                2606:4700:10::ac42:93f3                        -- link: enp0s5
   
   -- Information acquired via protocol DNS in 88.6ms.
   -- Data is authenticated: no; Data was acquired via local or encrypted transport: no
   -- Data from: network

   A Data from: network line confirms that the answer was fetched again after the cache was cleared.

4. Query the same hostname again when a quick cache repopulation check is needed.

   $ resolvectl query example.com
   example.com: 2606:4700:10::ac42:93f3                        -- link: enp0s5
                2606:4700:10::6814:179a                        -- link: enp0s5
                172.66.147.243                                 -- link: enp0s5
                104.20.23.154                                  -- link: enp0s5
   
   -- Information acquired via protocol DNS in 2.2ms.
   -- Data is authenticated: no; Data was acquired via local or encrypted transport: no
   -- Data from: cache

   The repeated query confirms that systemd-resolved has started building a fresh cache again after the flush.