dnsmasq Cache: Configure, Measure, and Flush Local DNS Safely

dnsmasq provides a lightweight local DNS cache that honors upstream TTLs by default; configure its upstream path carefully, because a resolver loop makes every lookup fail faster.

Caching can reduce repeat lookup latency and upstream traffic, but it is not a cure for broken authoritative DNS. The operational win comes from a small clear configuration plus measurements that show whether requests are hitting the cache.

Table of contents

• How the dnsmasq cache behaves
• Install and configure a caching resolver
• Avoid systemd-resolved and resolv.conf loops
• Verify cache hits and latency
• Flush and operate the cache
• How this fits the rest of the stack
• FAQ

How the dnsmasq cache behaves

Dnsmasq forwards a query to an upstream resolver, returns the answer, and keeps eligible records until their TTL expires. Subsequent clients can receive the cached answer locally. Negative answers may also be cached according to DNS rules. Dnsmasq does not invent freshness; the authoritative chain and upstream response determine the normal lifetime.

A larger cache stores more names but does not make a frequently changing record fresher. Options that force minimum or maximum TTLs should be used only with a clear reason because they override the domain owner’s cache policy and can prolong outages or increase query load.

Install and configure a caching resolver

sudo apt update
sudo apt install dnsmasq
sudoedit /etc/dnsmasq.d/cache.conf

cache-size=1000
listen-address=127.0.0.1
bind-interfaces
server=1.1.1.1
server=9.9.9.9
log-queries=extra

Choose upstream resolvers according to network policy, privacy, and private-zone requirements. Hard-coding public servers on a corporate network may break internal names. After editing, validate by restarting the service and checking its journal. Bind only to intended interfaces; exposing an unrestricted recursive resolver to the internet invites abuse.

Avoid systemd-resolved and resolv.conf loops

Modern Linux distributions may already run a local stub resolver. If resolv.conf points to dnsmasq while dnsmasq reads the same resolv.conf for its upstreams, the query loops back to itself. Decide which component owns the local listener and where dnsmasq gets upstream servers. A dedicated resolv file or explicit server entries make the chain visible.

readlink -f /etc/resolv.conf
ss -lntup | grep ':53'
sudo journalctl -u dnsmasq --since '10 minutes ago'

Port 53 conflicts are evidence of two resolver services competing, not a reason to kill processes randomly. Configure one listener or bind them to separate addresses with a deliberate forwarding relationship.

Verify cache hits and latency

Query the local listener twice and compare timing while watching logs. The first request should reach an upstream; the second should normally be served from cache if the record is eligible. Test positive and negative responses, and confirm clients actually use the local resolver rather than secure DNS in the browser or a VPN-provided server.

dig @127.0.0.1 example.com
dig @127.0.0.1 example.com
sudo journalctl -u dnsmasq -f

A tiny latency improvement on a laptop may not justify extra moving parts. On a busy network, reduced upstream traffic and resilience to brief resolver delays can be worthwhile. Measure the hit rate and error rate instead of treating cache size as a success metric.

Flush and operate the cache

Restarting dnsmasq clears its in-memory cache. A reload may clear cache depending on configuration and version behavior, so use the documented signal or service action for your system and verify with a query. Flushing should be a targeted incident step, not a cron job; frequent flushes erase the benefit and conceal why stale answers persist.

1. Confirm the authoritative record is correct
2. Query the upstream directly
3. Query dnsmasq and inspect TTLs
4. Flush only the affected cache layer
5. Verify clients use dnsmasq
6. Remove temporary query logging after diagnosis

DNS has caches in applications, operating systems, local forwarders, recursive resolvers, and browsers. Clearing one layer cannot change another. Trace the answer through the chain.

How this fits the rest of the stack

A local resolver supports the route to a deployed service, but it should remain observable. The RunxBuild hosting calculator models service and bandwidth needs, while the RunxBuild dashboard keeps application routes and logs available after DNS resolves.

Useful related references:

• What Does Flushing DNS Do? Clearing the Local Cache of Stale Answers
• Clear the DNS Cache on macOS: The One Command, and Why You Rarely Need It
• ERR_SSL_PROTOCOL_ERROR: Stop Clearing Your Cache, Check the Server
• Custom domains and certificates on RunxBuild

FAQ

How long does dnsmasq cache a DNS record?

Normally until the TTL supplied through DNS expires. Forced minimum or maximum TTL settings can change that behavior.

How do I clear the dnsmasq cache?

Restarting the dnsmasq service clears its in-memory cache. Verify the service action supported by your distribution and retest the query.

How large should cache-size be?

Base it on client count, working set, memory, and measured hit rate. A larger number does not fix stale or incorrect authoritative records.

Why does dnsmasq fail when systemd-resolved is running?

Both may compete for port 53 or form a forwarding loop. Decide which service owns the listener and define the upstream chain explicitly.

Can I expose dnsmasq to the public internet?

Do not expose an unrestricted recursive resolver. Bind it to loopback or trusted interfaces and enforce network access controls.