DNS Cache Explained

A DNS cache is temporary storage for answers returned by the Domain Name System. When your device asks for www.example.com, the answer can be saved for a short period so the next lookup is faster.

DNS caching is one of the main reasons the internet feels fast. Without caching, every repeated visit would need to start from the root nameservers, move through the TLD nameservers, reach the authoritative nameserver, and then return the final record. With caching, most repeat lookups are answered much earlier.

For the broader resolution path, start with What Is DNS. This guide focuses on the cache layers that sit along that path.

What a DNS Cache Stores

A DNS cache stores DNS response data for later reuse. That can include:

• A records and AAAA records that map names to IP addresses
• CNAME records that point one hostname to another
• MX records for mail delivery
• TXT records, including SPF, DKIM, and verification records
• NS records and delegation data used while walking the DNS tree
• Negative answers such as NXDOMAIN, meaning a name does not exist

Each cached answer is stored with timing information. In normal DNS, that timing is controlled by TTL, short for Time To Live.

Where DNS Caching Happens

DNS answers can be cached in several places before they reach an authoritative nameserver.

The recursive resolver cache usually matters most for public DNS changes. If Google Public DNS, Cloudflare DNS, Quad9, or an ISP resolver cached the old answer, users of that resolver may keep seeing it until the TTL expires.

How DNS Cache Lookup Works

Here is the simple version:

1. You visit www.example.com.
2. The browser checks whether it already has a cached answer.
3. If not, the operating system checks its resolver cache.
4. If not, the query goes to a recursive resolver such as 1.1.1.1, 8.8.8.8, or an ISP resolver.
5. If the recursive resolver has a valid cached answer, it returns it immediately.
6. If not, the recursive resolver asks the root, TLD, and authoritative nameservers.
7. The answer is returned and cached according to its TTL.

The next user asking the same recursive resolver for the same record can get a response from cache instead of triggering the full lookup again.

TTL: The Timer on Cached DNS

TTL is the number of seconds a resolver may cache a DNS record before refreshing it.

dig example.com A @8.8.8.8
 
;; ANSWER SECTION:
example.com.    3600    IN    A    192.0.2.10

In this example, 3600 means the answer can be cached for up to one hour. If you query the same resolver again later, the TTL often counts down:

dig example.com A @8.8.8.8
 
;; ANSWER SECTION:
example.com.    3174    IN    A    192.0.2.10

That countdown tells you the resolver is serving a cached response. When the timer reaches zero, the resolver should ask the authoritative nameserver again.

For record planning, see DNS TTL Best Practices.

DNS Cache and Propagation

DNS propagation is mostly cache expiry. When you change a record in your authoritative DNS provider, the authoritative nameserver can serve the new value quickly, but recursive resolvers may still have the old value cached.

Example:

1. app.example.com points to 192.0.2.10 with TTL 86400.
2. A resolver caches that answer at 09:00.
3. You change the record to 198.51.100.25 at 09:05.
4. That resolver may keep returning 192.0.2.10 until the original 24-hour TTL expires.

The important detail: the old TTL controls how long the old answer can remain cached. Lowering TTL at the same moment as the record change does not clear caches that already stored the old value.

For the full timing model, see DNS Propagation Explained.

Negative DNS Caching

DNS can also cache the fact that a name does not exist. This is called negative caching.

If a resolver asks for new.example.com before you create that record, it may receive NXDOMAIN and cache that negative answer. When you create the record a minute later, the resolver may still say the name does not exist until the negative cache expires.

Negative cache duration is controlled by the SOA record's negative-cache TTL. See What Is an SOA Record and NXDOMAIN Explained for the deeper mechanics.

How to Tell Whether an Answer Is Cached

Compare a public resolver with the authoritative nameserver.

# Ask a public recursive resolver
dig app.example.com A @1.1.1.1
 
# Ask the authoritative nameserver directly
dig app.example.com A @ns1.dnscale.eu

If the authoritative nameserver returns the new value but the public resolver returns the old one, the public resolver is probably serving cached data. Check the TTL in the resolver's answer to estimate how long that cache can remain valid.

You can also compare multiple public resolvers:

dig +short app.example.com A @1.1.1.1
dig +short app.example.com A @8.8.8.8
dig +short app.example.com A @9.9.9.9

Different answers usually mean different cache states, not that DNS servers are syncing with each other.

When to Flush DNS Cache

Flushing DNS cache clears local cached answers before they expire. It is useful when:

• You changed a record and want your own machine to test fresh data
• A browser still reaches an old IP address
• Your OS cache has stale data after a network or VPN change
• You are troubleshooting a local-only DNS problem

Flushing your local cache does not clear caches at public resolvers or ISP resolvers. For step-by-step commands on Windows, macOS, Linux, and browsers, use How to Flush Your DNS Cache.

Common DNS Cache Problems

The safest troubleshooting pattern is:

1. Query the authoritative nameserver directly.
2. Query one or more public resolvers.
3. Compare the answers and remaining TTLs.
4. Flush local cache only if the problem is local to your device or browser.

DNS Cache and Security

Because recursive resolvers serve cached answers to many users, attackers have historically tried to inject false records into resolver caches. This is called DNS cache poisoning.

Modern resolvers use defenses such as source-port randomization, query randomization, and DNSSEC validation. DNSSEC is especially important for signed zones because it lets validating resolvers reject forged answers instead of caching them.

DNS Cache in DNScale Operations

DNScale runs authoritative DNS. That means DNScale serves the source-of-truth records for zones hosted on the platform. Once you update a record, DNScale's authoritative side can answer with the new value quickly, but recursive resolvers outside DNScale still refresh based on TTL.

For planned changes:

1. Lower TTL 24-48 hours before the change.
2. Wait for the old TTL window to expire.
3. Change the record.
4. Verify the authoritative answer directly.
5. Restore a longer TTL after the new answer is stable.

This pattern reduces stale-cache windows without permanently increasing DNS query volume.

Related Topics

• What Is TTL -- how cache duration is set on DNS records
• DNS Propagation Explained -- why DNS changes appear at different times
• How to Flush Your DNS Cache -- clear browser and OS DNS caches
• Types of DNS Servers Explained -- recursive resolvers, forwarders, root, TLD, and authoritative servers
• DNS Cache Poisoning -- how forged answers can enter resolver caches
• DNS TTL Best Practices -- choosing practical TTLs for production records

Conclusion

DNS cache is not a separate DNS system. It is temporary storage inside the browsers, devices, routers, forwarders, and recursive resolvers that already participate in DNS resolution. Caching makes DNS fast and scalable, while TTL controls how long answers can be reused. When DNS changes appear delayed, compare authoritative and recursive answers before changing more records: most "propagation" problems are simply caches waiting for their timers to expire.