How to flush DNS cache on Linux and fix errors

What is DNS cache and why it fails in practice

The Domain Name System (DNS) acts as the phonebook of the internet, translating human-friendly domain names like marciocunha.net into numerical IP addresses that computers use to communicate. To speed up browsing and reduce network traffic, your operating system temporarily stores these responses in an area called cache. In practice, this means your computer doesn't need to ask the entire internet for a website's IP every time you try to visit it.

However, this convenience introduces a side effect well-known in corporate environments: when a server changes its IP address or a site is migrated to new infrastructure, your computer might keep trying to reach the old address stored in memory. In local servers or corporate networks, this propagation failure leads to frustrating connection errors that look completely random. That is precisely when you need to inspect what is stored and force a cache cleanup to restore normal data flow.

How to identify name resolution problems

Before applying any cleanup commands, the first step for a system administrator is to isolate the root cause of the failure. Often, the error is not in the local cache, but rather in an intermediate server or a misconfiguration in the DNS zone. To investigate this precisely, we use the dig utility, a powerful command-line tool for querying name servers directly.

In practice, dig allows us to completely bypass the operating system's cache and ask the source directly. If you want to know how to set up router QoS to eliminate network jitter and ensure stability during queries, it is crucial to first isolate whether the issue is route slowness or a domain response failure. Running precise diagnostics prevents you from wasting time restarting services that are working perfectly.

Inspecting the resolver with systemd-resolved

In modern Linux distributions such as Ubuntu, Debian, and Fedora, network management and name resolution are largely centralized in a service called systemd-resolved. This service acts as a local resolver that intercepts application requests and maintains an active cache in RAM. To check the current state of this cache, usage statistics, and configured upstream servers, we use the native resolvectl command.

When we run an inspection, we can clearly see how many queries succeeded, how many failed, and the current cache hit rate. If you notice bizarre discrepancies where a web browser opens the site but the command-line tool fails, the issue almost always lies in aggressive caching policies maintained by this service or even additional caching layers inside the browser itself.

Step-by-step guide to clearing DNS cache on Linux

When domain propagation fails and you are certain the records were updated at the source, it is time to flush the local cache. The procedure is fast but requires administrative privileges. The sequence below demonstrates how to restart and clear the system resolver cache safely.

1. Open the Linux terminal with superuser privileges and check the current status of the resolution service by running

   sudo systemctl status systemd-resolved

2. Flush the internal cache and reset the resolver statistics using the native command

   sudo resolvectl flush-caches

3. Validate that the cleanup worked and the cache was reset by querying the service status again with

   sudo resolvectl statistics

After executing these steps, the operating system will discard all outdated entries. Keep in mind that if you use local DNS servers like Pi-hole or chained corporate services, you may need to clear the cache on those central nodes as well to guarantee full effectiveness.

Validating propagation with the dig command

With the cache cleared, the next essential step is to validate whether new requests are fetching updated IP addresses. This is where the dig command becomes a network engineer's best friend. While web browsers might insist on keeping old data, dig performs a raw, transparent query to the authoritative server.

By running a query pointing to a trusted public server, such as Google's (8.8.8.8) or Cloudflare's (1.1.1.1), you can compare the response your machine is receiving with internet reality. If the returned IP is still the old one, the problem is no longer your local cache, but rather the Time to Live (TTL) set by the domain provider which has not yet expired across global root servers. To complement this implementation in production environments, see our related technical analyses on How to test motherboard fusible resistor with multimeter and How to configure router QoS to eliminate network jitter.

Conclusion and best practices in DNS management

Managing name resolution in Linux environments requires understanding that caching exists to optimize performance, but it can become an obstacle during server maintenance and migrations. Mastering tools like systemd-resolved and dig turns a seemingly mysterious problem into a quick, surgical diagnosis. With the right inspection and cleaning routine, you ensure your corporate infrastructure or local server responds with precision and agility.

Adopting best practices, such as checking TTL before major changes and documenting cleanup procedures, prevents hours of downtime and headaches. DNS is the invisible foundation of any modern network architecture; keeping it audited and under control equals resilience and stability for your entire technological operation.