Linux DNS Cache: systemd-resolved, nscd & dnsmasq Explained

📝 Introduction

Linux's modular design extends fully to DNS resolution — rather than a single OS-mandated caching service, different distributions, and even different configurations of the same distribution, can run entirely different resolver stacks, each with its own caching behavior and its own commands for inspection and flushing.

❓ Why There's No Single Mechanism

This variability is a direct consequence of Linux's philosophy of composable, swappable system components rather than a single monolithic networking stack. It's genuinely more flexible for advanced use cases, but it means a generic "how to flush DNS on Linux" answer doesn't exist the way it does for Windows — the correct command depends entirely on what's actually installed and active on that specific system.

⚙️ systemd-resolved

On modern distributions using systemd — which covers a large majority of current mainstream Linux installations — systemd-resolved is the most commonly active local DNS resolver and cache. Check its status with systemctl status systemd-resolved, view cache statistics with resolvectl statistics, and flush its cache with sudo resolvectl flush-caches. This is the resolver most users troubleshooting a recent Ubuntu, Fedora, or Debian-based desktop system are likely encountering.

💾 nscd (Name Service Cache Daemon)

nscd is an older, more general-purpose caching daemon that caches not just DNS lookups but also other name service lookups like user and group information, common on older or more traditional Linux server configurations. Restarting the service — sudo service nscd restart or the equivalent for your init system — is the standard way to clear its cache, since nscd doesn't typically offer a more granular flush-only command.

📶 dnsmasq

dnsmasq is a lightweight DNS forwarder and cache commonly used both on desktop Linux systems and extensively in router and embedded firmware. Where dnsmasq is running as the local resolver, restarting its service — sudo systemctl restart dnsmasq on systemd-based systems — clears its cache, and its configuration file typically allows adjusting cache size and behavior directly for more advanced tuning.

❌ Distributions Without Local Caching

Many minimal server distributions, and most container base images, run no local DNS caching resolver at all by default, instead forwarding every query directly to whatever resolver is configured in /etc/resolv.conf. On these systems, there's genuinely nothing local to flush — any caching happening is entirely at the network-configured resolver, not on the local machine itself.

🔍 How to Identify Your Active Resolver

📶 NetworkManager's Role

On many modern desktop distributions, NetworkManager handles overall network configuration and commonly hands DNS resolution off to systemd-resolved automatically, meaning the two work together rather than being separate concerns — understanding this relationship matters specifically when troubleshooting DNS on a NetworkManager-managed desktop, since the resolver configuration often isn't set manually in the traditional way.

📦 DNS Caching Inside Containers

Containers typically inherit DNS configuration from their runtime rather than running their own independent caching resolver, and Docker specifically has its own embedded DNS server for container-to-container name resolution within a user-defined network — a distinct layer worth being aware of separately from host-level Linux DNS caching when debugging containerized application connectivity issues.

📚 Distribution-by-Distribution Notes

Ubuntu and Fedora desktop editions typically ship with systemd-resolved active by default. Many traditional server-oriented distributions and minimal cloud images often run no local cache at all. Router and embedded Linux firmware overwhelmingly favor dnsmasq for its small footprint. These are general tendencies rather than absolute rules — always verify directly on the specific system rather than assuming based on distribution name alone.

📊 Comparison Tables

🏢 Enterprise & Server Considerations

Organizations managing mixed Linux server fleets should document which resolver stack is standard across their environment as part of their infrastructure runbooks, since assuming a single universal flush command across a heterogeneous fleet is a common and avoidable source of wasted troubleshooting time during incidents.

❌ Common Mistakes

✅ Command Reference Checklist

• Identify the active resolver before attempting any flush command
• Use resolvectl flush-caches for systemd-resolved
• Restart the relevant service for nscd or dnsmasq
• Check /etc/resolv.conf if no local resolver is found

🎓 Expert Tips

💼 Daily Practical Use Cases

System administrators use this reference when troubleshooting DNS across a mixed Linux server fleet with varying resolver stacks. Developers deploying to Linux-based cloud environments use it to understand DNS behavior differences between local development and production. Networking students use it to appreciate how Linux's modular design plays out concretely in a real subsystem.

📚 Glossary

📋 Related Tools & Guides Comparison

FAQ

🔗 More Guides