DNS Caching and TTL Explained: Cache, Propagation and Flush DNS 2026

Table of Contents

DNS Caching and TTL Explained: How DNS Cache Works, TTL Values, Negative Caching and Propagation

DNS caching is one of the fundamental mechanisms that allows the Domain Name System (DNS) to operate efficiently at Internet scale. It reduces lookup latency, limits unnecessary traffic to authoritative name servers, and helps applications resolve domain names without repeating the complete DNS resolution process for every request.

When a user visits a hostname such as www.example.com, the DNS answer does not always come directly from an authoritative server. A recursive resolver may already have the necessary information in its cache and can return it immediately.

The mechanism that normally determines how long cached DNS information remains usable is the Time to Live (TTL). However, DNS caching is more complex than simply storing an IP address for a fixed number of seconds.

Modern DNS resolvers work with resource-record sets (RRsets), cache certain negative responses, handle CNAME chains with separate TTLs, and may refresh popular records before their cached copies expire. Some implementations can even serve expired DNS data temporarily when authoritative infrastructure becomes unavailable.

Understanding these mechanisms is essential for DNS troubleshooting, cloud migrations, website availability, and network administration.

In this guide, you will learn how DNS caching and TTL work, what actually happens during DNS propagation, why NXDOMAIN responses may persist after a record is created, and how to troubleshoot real DNS issues using tools such as dig.

If you are new to the underlying architecture, start with our DNS Explained guide. For the differences between A, AAAA, CNAME, MX, TXT, NS, SOA, and other records, see DNS Record Types Explained.

What Is DNS Caching?

DNS caching is the temporary storage of DNS information so that repeated queries can often be answered without performing the entire DNS resolution process again.

Suppose a client requests the IPv4 address of:

www.example.com

A recursive DNS resolver obtains an authoritative answer:

www.example.com. 3600 IN A 192.0.2.10

The resolver can cache the A record data and answer subsequent matching requests from its cache.

Without a useful cached answer, DNS resolution may involve querying the root, top-level domain (TLD), and authoritative DNS infrastructure.

A simplified first lookup looks like this:

Client
   |
   v
Recursive Resolver
   |
   v
Root / TLD DNS
   |
   v
Authoritative DNS
   |
   v
Answer stored in cache
   |
   v
Client receives answer

Once relevant data is cached, subsequent lookups can be much shorter:

Client
   |
   v
Recursive Resolver
   |
   v
Cached DNS Answer
   |
   v
Client

This reduces response times and unnecessary network traffic.

DNS caching is therefore an essential part of the system’s scalability rather than an optional performance enhancement.

Why DNS Caching Matters

Imagine that every request for a popular domain required a resolver to contact the complete DNS hierarchy again.

The number of unnecessary queries would increase substantially, adding latency and placing additional load on authoritative infrastructure.

Caching addresses this problem in several ways.

Faster DNS responses: A resolver can answer repeated queries from locally stored information instead of making new upstream requests.

Reduced authoritative-server load: Frequently requested records do not need to be retrieved from authoritative infrastructure every time.

Lower network overhead: Fewer DNS requests travel through the wider Internet.

Improved scalability: Recursive resolvers can serve large numbers of clients efficiently.

Potentially greater resilience: Some resolver implementations can continue serving previously cached information during temporary authoritative-server failures.

These benefits are especially important for high-traffic websites, enterprise applications, cloud services, and global content delivery networks.

DNS Records, RRsets, and Cache Behavior

An important concept often missing from introductory explanations is the resource-record set, or RRset.

An RRset contains DNS resource records sharing the same owner name, DNS class, and record type.

Consider:

app.example.com. 300 IN A 192.0.2.10
app.example.com. 300 IN A 192.0.2.11
app.example.com. 300 IN A 192.0.2.12

These three A records belong to the same A RRset.

A simplified representation is:

app.example.com
       |
       v
     A RRset
       |
  +----+----+
  |    |    |
  v    v    v
 .10  .11  .12

DNS caching operates around these record sets rather than treating every address as an unrelated cache object with an independent expiration policy.

This behavior is important when working with multiple IP addresses, load distribution, and DNSSEC.

The technical rules governing RRsets and TTL consistency are discussed in RFC 2181 — Clarifications to the DNS Specification.

Why RRsets matter

Suppose an application uses three A records to distribute clients across three servers.

Changing the set of addresses can affect the complete cached RRset. A recursive resolver may continue returning the previously cached set until its applicable cache lifetime expires.

This means that adding or removing an individual address does not guarantee that every client immediately receives the new set.

It also means DNS-based address rotation is not equivalent to an application-aware load balancer.

A dedicated load-balancing system can provide health checks, connection handling, TLS termination, session policies, and other capabilities that ordinary DNS caching does not inherently provide.

What Is DNS TTL?

TTL stands for Time to Live.

It is a field in DNS resource records that specifies, in seconds, how long DNS data may normally remain fresh in a cache.

For example:

www.example.com. 3600 IN A 192.0.2.10

Here:

www.example.com. is the owner name.
3600 is the TTL in seconds.
IN identifies the Internet DNS class.
A identifies the IPv4 address record type.
192.0.2.10 is the address.

A TTL of 3600 represents one hour.

A resolver receiving this RRset can normally reuse the information until its remaining cache lifetime expires.

How TTL decreases over time

Suppose a resolver receives the A RRset at 10:00 with an initial TTL of 3600 seconds.

A simplified timeline is:

Time	Approximate remaining TTL
10:00	3600 seconds
10:10	3000 seconds
10:30	1800 seconds
10:50	600 seconds
11:00	Expired

This is a conceptual example.

Actual observations can differ depending on resolver behavior, refresh mechanisms, caching policies, and whether requests reach the same recursive resolver instance.

TTL is not a global domain setting

A common misconception is that a domain has one universal TTL.

Different DNS RRsets can have different TTL values.

For example:

example.com.      3600 IN A  192.0.2.10
www.example.com.   300 IN A  192.0.2.20
example.com.      7200 IN MX 10 mail.example.com.

The first A RRset has a one-hour TTL.

The second A RRset has a five-minute TTL.

The MX RRset has a two-hour TTL.

Changing one record’s TTL does not automatically change the caching behavior of every other record associated with the domain.

This distinction becomes particularly important during website migrations, mail-server changes, and DNS failover operations.

How DNS TTL Actually Works

Assume an authoritative DNS server publishes:

app.example.com. 3600 IN A 192.0.2.10

At 10:00, a recursive resolver obtains and caches this information.

At 10:30, a client asks the same resolver for the A record. If the cached data remains fresh, the resolver can return the old address without contacting the authoritative server.

Now suppose the authoritative record changes to:

app.example.com. 3600 IN A 192.0.2.20

The authoritative server now publishes the new IP address, but resolvers holding fresh copies of the previous RRset are not automatically notified.

They can continue returning the old address until the relevant cached data expires or is refreshed through another applicable mechanism.

The essential sequence is:

Authoritative record changes
            |
            v
Resolver still has old RRset
            |
            v
Old cache lifetime expires
            |
            v
Resolver refreshes DNS data
            |
            v
New RRset becomes available

DNS is a distributed system. Different recursive resolvers can refresh at different times.

That is why two users may temporarily receive different answers for the same hostname.

What Happens When DNS TTL Reaches Zero?

Under ordinary caching behavior, when the TTL reaches zero, the cached data is no longer fresh.

The resolver generally needs to obtain fresh DNS information before using it as an ordinary cached answer again.

However, this does not necessarily mean the expired information must immediately disappear from the resolver’s memory.

Modern recursive DNS implementations may support Serve Stale, a resilience mechanism defined by RFC 8767 — Serving Stale Data to Improve DNS Resiliency.

Serve Stale allows resolvers to retain expired DNS data and return it under defined circumstances, particularly when fresh information cannot be obtained because authoritative DNS servers are unavailable.

Therefore, two concepts must be distinguished:

Cache expiration: The normal freshness lifetime has ended.

Physical cache removal: The resolver has discarded the stored data entirely.

These events do not always happen simultaneously.

What does TTL 0 mean?

A TTL of zero means the data should not be retained as a reusable fresh cache entry beyond the current resolution transaction.

It does not mean that the record does not exist.

It also does not mean that the current DNS response is unusable.

For example:

app.example.com. 0 IN A 192.0.2.10

The resolver or client can use this answer for the current lookup, but it should not treat the RRset as fresh cached data for subsequent independent queries.

Extremely short TTLs are therefore not automatically beneficial. They can increase authoritative DNS query volume and complicate infrastructure behavior.

Where DNS Information Is Cached

Another common misconception is that DNS caching happens in only one place.

In reality, several layers may participate in resolving a hostname.

Application / Browser
         |
         v
Operating System
         |
         v
Local DNS Forwarder
         |
         v
Recursive DNS Resolver
         |
         v
Authoritative DNS

Depending on the environment, DNS information or DNS-related state can exist in browsers, operating systems, local forwarding services, home routers, enterprise DNS servers, ISP resolvers, and public recursive DNS services.

These layers do not necessarily share the same cache.

For example, a laptop and smartphone connected to the same network may temporarily produce different results because of their local DNS state, encrypted DNS settings, or resolver configuration.

Likewise, two computers using different recursive resolvers may receive different answers even if both systems have completely fresh local caches.

Browser DNS behavior

Modern browsers add another layer of complexity.

A browser may reuse previously resolved addresses, maintain an internal DNS cache, use DNS over HTTPS (DoH), reuse existing TCP or QUIC connections, or operate through a proxy.

Consequently, if:

dig example.com A

returns the expected IP address but the website still opens through an unexpected server, the issue may not be DNS caching.

Possible causes include an existing browser connection, a service worker, a redirect, HTTP caching, a CDN, or a browser using a different DNS resolver.

The correct approach is to identify which layer is producing the unexpected behavior before changing DNS again.

High TTL vs Low TTL: Which Is Better?

TTL selection involves a tradeoff between cache efficiency and responsiveness to DNS changes.

Characteristic	Higher TTL	Lower TTL
Cache reuse	Generally greater	Generally lower
Repeated lookup latency	Often reduced	May increase
Authoritative query load	Usually lower	Usually higher
Response to record changes	Potentially slower	Potentially faster
Migration flexibility	Lower	Higher
Suitability for stable records	Often useful	Depends on requirements

A low TTL is not automatically better, and a high TTL is not automatically worse.

The appropriate value depends on the type of DNS record, how frequently it changes, resolver behavior, expected traffic, availability architecture, and the operational requirements of the service.

Example TTL values

TTL 60 — one minute: Sometimes used for services requiring frequent DNS updates. It increases potential query frequency and does not guarantee one-minute failover.

TTL 300 — five minutes: A common operational compromise between cache reuse and flexibility.

TTL 3600 — one hour: Often suitable for reasonably stable records that do not change frequently.

TTL 86400 — one day: Can be appropriate for highly stable DNS data, but requires careful planning before migrations.

These examples are not universal recommendations. Providers and resolvers may enforce minimum, maximum, or automatic TTL policies.

Lowering TTL Does Not Clear Existing DNS Caches

One of the most important DNS migration principles is that lowering a TTL does not retroactively modify records already stored by recursive resolvers.

Suppose an authoritative server publishes:

app.example.com. 86400 IN A 192.0.2.10

A resolver receives that information at 09:00.

Five minutes later, an administrator changes the authoritative TTL to:

app.example.com. 300 IN A 192.0.2.10

The resolver that already cached the RRset with the previous TTL does not automatically receive a notification about the new value.

It may continue using the old information for its remaining normal lifetime.

This is why lowering the TTL at the same moment as changing the destination address is generally insufficient for a carefully controlled migration.

The TTL should be reduced well before the planned migration, allowing previously cached high-TTL answers to age out.

DNS Propagation Explained Correctly

The phrase DNS propagation is widely used to describe how long DNS changes take to become visible.

However, it can create the misleading impression that new DNS records are actively pushed to every resolver on the Internet.

Ordinary recursive DNS caching does not work that way.

A more accurate model is:

Authoritative DNS changes
            |
            v
Resolver A has no cached answer
            |
            v
Resolver A obtains new data

Resolver B still has valid old data
            |
            v
Resolver B waits for expiration
            |
            v
Resolver B eventually refreshes

Much of what administrators describe as propagation is actually the expiration and replacement of cached DNS information across independently operating resolvers.

However, caching is not the only factor that can affect DNS changes.

Delegation records, DNSSEC configuration, split-horizon DNS, negative caching, client behavior, and provider-specific implementations may also play a role.

Why two DNS resolvers return different IP addresses

Suppose:

www.example.com

changes from:

192.0.2.10

to:

192.0.2.20

Resolver A queried just before the change and still has a valid cached RRset.

Resolver B had no cached answer and queried after the authoritative update.

Resolver A can temporarily return the old address while Resolver B returns the new address.

Both results can be consistent with normal DNS caching behavior.

This does not necessarily mean one resolver is broken.

Is DNS propagation always 24–48 hours?

No.

There is no universal rule requiring every DNS record change to take 24 or 48 hours.

The actual transition depends on previously cached TTL values, the type of change, resolver policies, negative caching, delegation, and application behavior.

A five-minute TTL may allow many resolvers to refresh quickly, but it does not guarantee every application and client will switch within exactly five minutes.

The correct approach is to measure actual DNS responses rather than rely on a generic propagation timer.

Record Changes vs Nameserver Delegation Changes

Changing an A record and changing a domain’s authoritative nameservers are different operations.

An A record update primarily changes authoritative zone data and influences recursive caches containing the corresponding RRset.

Changing nameservers can additionally affect the delegation chain.

During a nameserver migration, administrators may need to verify parent-zone delegation, NS records, glue records, authoritative-server configuration, and DNSSEC information.

For example, if the parent zone delegates a domain to outdated nameservers, simply shortening the A record TTL does not resolve the underlying delegation problem.

When investigating these issues, dig +trace can help reveal the path through the DNS hierarchy.

For an introduction to the wider architecture, see DNS Explained.

Positive DNS Caching

Positive caching occurs when a resolver stores successfully retrieved DNS information.

For example:

app.example.com. 3600 IN A 192.0.2.10

The resolver may cache the associated A RRset and reuse it while it remains fresh.

Positive caching applies to more than IPv4 addresses.

DNS data involving AAAA, MX, NS, TXT, SRV, SOA, and other record types can also be cached according to applicable DNS rules.

To understand the meaning of each type, consult DNS Record Types Explained.

Negative DNS Caching

DNS can also cache certain negative answers.

This mechanism is called negative DNS caching.

Suppose a client requests:

newapp.example.com

but the name does not exist in the authoritative DNS zone.

The response may indicate:

NXDOMAIN

Instead of asking the authoritative server again for every identical request, the recursive resolver can temporarily cache the negative result.

Negative caching reduces repeated unnecessary queries and improves DNS scalability.

It is standardized in RFC 2308 — Negative Caching of DNS Queries.

What controls negative caching TTL?

Negative caching does not simply use the TTL of a missing A or AAAA record, because that record does not exist.

For conventional negative responses, RFC 2308 specifies an effective negative TTL based on the smaller of the relevant SOA record’s TTL and its SOA MINIMUM field.

Conceptually:

Negative DNS answer
         |
         v
    SOA information
         |
    +----+----+
    |         |
 SOA TTL   SOA MINIMUM
    |         |
    +----+----+
         |
         v
   Smaller value
         |
         v
 Negative cache TTL

Resolver implementations may also impose additional caching limits.

This distinction matters when a DNS name did not exist shortly before an administrator created its record.

Why a new hostname can still return NXDOMAIN

Consider this timeline:

At 10:00, a recursive resolver queries newapp.example.com.

The name does not exist, so the resolver receives and caches an NXDOMAIN response.

At 10:02, an administrator creates:

newapp.example.com. 300 IN A 192.0.2.50

The authoritative DNS server can now return the new address.

However, the recursive resolver may still hold a valid cached negative answer.

Until that negative cache entry expires or is otherwise invalidated, some clients can continue receiving NXDOMAIN.

This is why creating a DNS record does not always make the name immediately resolvable through every recursive resolver.

NXDOMAIN vs NODATA

Not every negative DNS response means that a domain name does not exist.

NXDOMAIN means the queried name does not exist.

NODATA describes a different situation: the DNS name exists, but no data is available for the requested record type.

For example, a hostname may have an A record but no AAAA record.

A query for its AAAA record may return NOERROR without the requested address data.

This does not mean the hostname itself is nonexistent.

The distinction is important when troubleshooting IPv6 records, mail services, and applications requesting multiple DNS record types.

When investigating a negative response, inspect both the DNS response code and the requested record type.

DNS Serve Stale Explained

Traditional explanations often suggest that a resolver must stop returning cached data as soon as its TTL expires.

Modern recursive DNS systems can support a more resilient approach.

RFC 8767 defines Serve Stale, allowing expired cached DNS data to be used under controlled conditions when fresh information cannot be obtained.

Consider an application whose authoritative DNS servers become temporarily unreachable.

A recursive resolver previously cached the correct A RRset, but its normal TTL has expired.

Without Serve Stale, a fresh lookup may fail because the authoritative servers cannot be reached.

With Serve Stale enabled and appropriate conditions satisfied, the resolver may return its previously cached information rather than immediately failing.

Cached DNS data expires
            |
            v
Resolver attempts refresh
            |
            v
Authoritative DNS unavailable
            |
            v
Serve Stale permitted?
            |
            v
Expired data returned temporarily

The objective is improved resilience during DNS outages.

Serve Stale should not be interpreted as permission to ignore TTL indefinitely. It is an exceptional mechanism with implementation-dependent controls and defined behavior.

Administrators should account for it when investigating persistent old answers after TTL expiration.

Resolver Prefetch and Unexpected TTL Changes

Some recursive resolvers can refresh frequently requested DNS data before the existing cached copy expires.

This mechanism is commonly called prefetch.

Without prefetch, an administrator might expect TTL values to decrease continuously:

However, a resolver may refresh popular DNS data while the current cached version is still usable.

The observed sequence could look like:

Query 1: TTL 400
Query 2: TTL 300

Resolver refreshes the RRset

Query 3: TTL 3600

A suddenly increasing TTL does not necessarily mean the DNS record changed.

It may simply indicate that the resolver obtained a fresh copy.

For accurate troubleshooting, compare both the answer content and the TTL while keeping resolver implementation details in mind.

CNAME Caching Uses Separate RRsets

CNAME records introduce another important caching consideration.

Suppose a DNS zone contains:

www.example.com. 300 IN CNAME app.example.net.

The target hostname has:

app.example.net. 3600 IN A 192.0.2.50

These are two different RRsets with independent TTL values.

www.example.com
       |
       | CNAME TTL 300
       v
app.example.net
       |
       | A TTL 3600
       v
192.0.2.50

The resolver can cache both RRsets.

They do not necessarily expire at the same time.

Therefore, changing the CNAME does not automatically invalidate every cached address associated with its previous target.

Similarly, changing the target’s A record does not rewrite existing caches containing that RRset.

When troubleshooting CNAME behavior, inspect both the alias and the destination.

For example:

dig www.example.com CNAME
dig app.example.net A

Where applicable, inspect the full response, including the answer section, instead of assuming that one query reveals every relevant cache entry.

DNS Caching and Multiple A Records

Multiple addresses can belong to the same A RRset:

app.example.com. 300 IN A 192.0.2.10
app.example.com. 300 IN A 192.0.2.11
app.example.com. 300 IN A 192.0.2.12

Applications may receive multiple addresses and choose among them according to their own connection behavior.

DNS does not inherently verify that every application server behind these addresses is healthy.

If one server becomes unavailable, clients may still try its address until DNS data or application behavior changes.

A dedicated load balancer can provide active health checks, connection handling, and application-aware routing.

DNS-based traffic distribution can complement such systems, but it should not automatically be treated as equivalent to them.

DNS TTL and Cloudflare Proxying

Managed DNS providers can introduce additional behavior.

Cloudflare distinguishes between DNS-only and proxied records.

With a DNS-only A record, the public DNS answer generally exposes the configured origin address.

With a proxied hostname, public DNS responses generally direct clients to Cloudflare’s edge network rather than directly to the origin server.

This distinction affects how administrators interpret DNS updates.

Cloudflare proxied records

According to Cloudflare’s DNS TTL documentation, proxied records use an automatic TTL of 300 seconds.

That setting is managed by Cloudflare rather than manually edited as a conventional DNS-only TTL.

Importantly, changing the origin address behind a proxied hostname does not necessarily change the public DNS answer to the new origin IP.

The public answer can continue directing users to Cloudflare’s network.

Cloudflare DNS-only records

DNS-only records support configurable TTL values within Cloudflare’s documented limits.

For these records, changes to the public address are more directly affected by recursive DNS caching.

When investigating a Cloudflare-hosted service, distinguish between:

The authoritative DNS record configuration
The DNS response returned to clients
Cloudflare-to-origin connectivity
HTTP caching at Cloudflare’s edge

These are separate parts of the request path.

A fresh DNS answer does not guarantee that cached HTML or images have been refreshed, and a CDN cache purge does not automatically flush every recursive DNS cache.

How to Inspect DNS TTL Using dig

The dig utility is one of the most useful tools for DNS troubleshooting.

It can query recursive resolvers, inspect TTLs, retrieve specific record types, and help diagnose delegation problems.

Check an A record

Run:

dig example.com A

An answer might contain:

example.com. 3600 IN A 192.0.2.10

The TTL is the number immediately before the DNS class and record type.

When querying a caching recursive resolver repeatedly, that TTL may decrease as the cached RRset ages.

For a concise response, use:

dig +noall +answer example.com A

This is useful when comparing the results of multiple resolvers.

Query Cloudflare DNS

Cloudflare’s public recursive resolver is available at:

dig @1.1.1.1 example.com A

Query Google Public DNS

Google Public DNS can be queried with:

dig @8.8.8.8 example.com A

Compare the answers:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Different answers may indicate different cache histories.

However, the difference could also involve resolver policies, geographic routing, DNSSEC validation, or provider-specific behavior.

Do not assume that every differing result is caused by stale caching.

Find the authoritative nameservers

Start with:

dig example.com NS

Suppose the result includes:

ns1.example.net

You can then query that server directly:

dig @ns1.example.net example.com A

For a more controlled comparison, use the exact authoritative server relevant to the DNS zone.

Compare authoritative and recursive answers

Consider:

Authoritative response:

example.com. 300 IN A 192.0.2.20

Recursive response:

example.com. 600 IN A 192.0.2.10

The recursive resolver is still returning an older address.

An existing valid cache entry is a likely explanation, although the complete configuration should be checked before reaching a final diagnosis.

Comparing authoritative and recursive responses is one of the most useful DNS troubleshooting techniques.

Use dig +trace for delegation analysis

Run:

dig +trace example.com

This follows the DNS delegation path toward the authoritative infrastructure.

It is particularly useful when investigating nameserver changes, delegation errors, or parent-zone problems.

However, dig +trace does not reveal what every recursive resolver has cached.

Use direct recursive queries to examine a particular resolver’s answer, and use +trace to investigate the delegation path.

For additional command-line troubleshooting techniques, see our Linux Network Tools Guide.

How to Flush DNS Cache on Windows

Windows provides a straightforward command for clearing the local DNS client resolver cache.

Open Command Prompt with the required permissions and run:

ipconfig /flushdns

This clears the relevant Windows DNS resolver cache.

It does not clear cached data stored by your ISP, Google Public DNS, Cloudflare’s recursive resolvers, or an enterprise DNS server.

It also does not necessarily remove every address retained inside an application or browser.

If the problem persists after flushing Windows DNS, determine which resolver answered the query and whether the browser is using another DNS path.

How to Flush DNS Cache on Linux

Linux systems do not all use the same DNS caching mechanism.

The correct procedure depends on the installed resolver stack.

For systems using systemd-resolved, you can commonly flush the cache with:

sudo resolvectl flush-caches

You can inspect resolver configuration using:

resolvectl status

And view resolver statistics using:

resolvectl statistics

Other environments may use dnsmasq, Unbound, BIND, nscd, NetworkManager, or a separate enterprise DNS service.

Do not blindly restart DNS services without identifying the active resolver implementation.

A service restart can interrupt DNS operations without addressing an upstream cache or authoritative DNS problem.

For broader Linux administration practices, see our Linux Server Administration guide.

Why Flushing Your Computer Does Not Flush the Internet

Consider a client using an ISP’s recursive DNS resolver:

Computer
   |
   v
Local DNS Cache
   |
   v
ISP Recursive Resolver
   |
   v
Authoritative DNS

You clear the computer’s local DNS cache.

The next request reaches the ISP’s resolver.

If that resolver still has a valid cached copy of the old RRset, it can return the old address.

Your local cache has been cleared, but the upstream cache has not.

In general, a client cannot force arbitrary remote recursive resolvers to discard their cached information.

Therefore, repeated local cache flushing is not a reliable solution for a remote resolver holding valid older data.

DNS Caching During Server Migrations

DNS changes should be planned around the previous TTL, not merely the new TTL configured at the moment of migration.

Suppose a service uses:

Current server: 192.0.2.10
New server:     192.0.2.20
Current TTL:    86400 seconds

The current TTL is one day.

Changing the destination IP and lowering the TTL to 300 seconds at the same moment will not force every resolver to immediately discard its previously cached answer.

A safer DNS migration workflow

Step 1: Lower the TTL in advance.

Reduce the TTL of the relevant DNS RRsets before the planned migration.

Step 2: Wait for old high-TTL caches to expire.

Allow sufficient time for previously cached responses using the original TTL to age out.

Step 3: Prepare the new infrastructure.

Confirm that the destination server is reachable and ready to handle production traffic.

Step 4: Change the authoritative DNS record.

Update the relevant record to reference the new destination.

Step 5: Keep the old infrastructure available temporarily.

Where practical, maintain both environments during the transition so clients with older cached data can still reach the application.

Step 6: Monitor DNS and application behavior.

Compare responses from different recursive resolvers and verify actual HTTPS or application connectivity.

Step 7: Increase TTL later if appropriate.

Once the migration has stabilized, consider restoring a longer TTL for efficient caching.

This process reduces the risk of preventable downtime.

Why the old server may need to remain online

After a change, one resolver may return:

192.0.2.20

while another still returns:

192.0.2.10

If both servers can serve the application correctly, users may continue operating normally.

If the old server is immediately removed, clients using its cached address may experience failed connections.

A planned overlap period is therefore often safer than an immediate shutdown.

DNS TTL and Failover

Short TTL values are sometimes used to support DNS-based failover.

For example, a system may change its DNS address from a failed primary server to a backup server.

Primary server fails
         |
         v
Failure detected
         |
         v
DNS updated to backup IP
         |
         v
Recursive caches refresh
         |
         v
Clients establish new connections

However, a TTL of 60 seconds does not guarantee every user will switch to the backup server within one minute.

Actual recovery time may also include health-check detection, DNS control-plane updates, authoritative publication, recursive cache refreshes, and application reconnect behavior.

Existing connections, local DNS state, and Serve Stale mechanisms may introduce additional differences.

TTL is only one component of failover time.

For services requiring rapid recovery, DNS-based mechanisms should be evaluated alongside load balancing, high availability, and application-level resilience strategies.

DNS Cache vs Browser, HTTP, and CDN Caches

DNS caching and content caching are different mechanisms.

DNS cache

A DNS cache stores information used during name resolution.

For example:

example.com
    |
    v
192.0.2.10

HTTP cache

An HTTP cache can store web resources such as HTML, images, CSS, or JavaScript according to applicable caching rules.

For example:

https://example.com/image.jpg
             |
             v
       Cached content

CDN cache

A content delivery network can cache application resources at distributed edge locations.

Client
   |
   v
DNS Resolution
   |
   v
CDN Edge
   |
   v
Cached Web Content

A website can have perfectly fresh DNS while still serving stale HTML from a CDN.

Likewise, changing a CDN cache setting does not necessarily change cached DNS addresses.

Before troubleshooting, identify whether the unexpected result concerns name resolution, browser connection state, HTTP caching, or CDN content delivery.

Split-Horizon DNS Can Look Like a Cache Problem

Some organizations intentionally return different DNS answers depending on the requesting network.

This is commonly called split-horizon DNS or split DNS.

For example, an internal corporate resolver might return:

portal.example.com -> 10.10.20.30

A public resolver might return:

portal.example.com -> 203.0.113.30

Both answers may be correct within their respective environments.

A VPN user may receive a private address, while an external user receives a public address.

This is not necessarily caused by stale DNS caching.

When comparing answers, determine which resolver is being queried and whether the network intentionally uses different DNS views.

Ten Common DNS Caching Mistakes

Understanding common errors can prevent unnecessary configuration changes.

1. Assuming every DNS update is immediate

Authoritative servers may publish new data while remote resolvers continue using older cached information.

2. Treating TTL as one universal domain timer

Different RRsets can have different TTL values and cache lifetimes.

3. Lowering TTL at the moment of migration

Resolvers may still hold answers obtained under the previous higher TTL.

4. Assuming expired data must instantly disappear

Serve Stale implementations can retain expired information for controlled use during failures.

5. Ignoring negative caching

A hostname created after an earlier NXDOMAIN response may remain temporarily unresolved through some recursive resolvers.

6. Confusing NXDOMAIN with NODATA

A nonexistent hostname is not the same as an existing hostname lacking a requested record type.

7. Treating a CNAME chain as one RRset

The alias and its target records can have different TTLs.

8. Flushing the local cache repeatedly

Local cache flushing does not automatically invalidate remote resolver caches.

9. Blaming DNS for browser or CDN problems

HTTP caching, service workers, existing connections, proxies, and CDN behavior can create symptoms that resemble stale DNS.

10. Assuming every DNS change takes 24–48 hours

Real timing depends on previous TTL values, cache state, delegation, resolver behavior, and the nature of the DNS update.

Complete DNS Cache Troubleshooting Workflow

When a hostname returns an unexpected address or fails to resolve, follow a structured diagnostic process.

Step 1: Query your configured resolver

dig example.com A

Record the answer, TTL, response code, and server that answered.

Step 2: Compare public recursive resolvers

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Check whether different resolvers return different answers.

Step 3: Identify the authoritative nameservers

dig example.com NS

Verify which nameservers are responsible for the zone.

Step 4: Query authoritative DNS directly

dig @AUTHORITATIVE_SERVER example.com A

Compare the authoritative result with the recursive responses.

Step 5: Check the exact record type

Do not investigate only A records if the application also depends on IPv6, aliases, or mail routing.

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com NS

Step 6: Investigate negative answers

If a recently created hostname returns NXDOMAIN, compare its recursive response with the authoritative answer.

Check SOA information and the applicable negative caching behavior.

Step 7: Inspect delegation where necessary

For suspected nameserver or delegation problems, run:

dig +trace example.com

Examine parent delegation, authoritative NS records, glue records where relevant, and DNSSEC configuration.

Step 8: Check local resolver state

If public DNS returns the expected answer but one device still behaves differently, inspect the operating system’s resolver configuration and cache.

Flush the relevant local cache only when appropriate.

Step 9: Inspect browser and application behavior

Consider DNS over HTTPS, existing connections, HTTP redirects, CDN caching, proxies, and service workers.

Step 10: Verify the actual application

Even correct DNS does not guarantee a working website.

For example:

curl -I https://example.com/

The application may still fail because of TLS problems, routing, firewall restrictions, server configuration, or load-balancer behavior.

For the networking layers involved in these requests, continue with TCP/IP Explained.

Quick diagnostic decision tree

Unexpected DNS answer
         |
         v
Query recursive resolver
         |
         v
Is the result expected?
    /             \
   No             Yes
   |               |
   v               v
Query           Check local,
authoritative   browser, proxy,
DNS             and app state
   |
   v
Authoritative answer correct?
    /             \
   Yes             No
   |                |
   v                v
Investigate      Fix DNS zone
cache, TTL,       or delegation
negative cache,
resolver policy
   |
   v
Verify application

A structured workflow is more reliable than repeatedly changing DNS records or clearing caches without identifying the source of the problem.

Frequently Asked Questions

What is DNS caching?

DNS caching is the temporary storage of DNS information so repeated requests can often be answered without repeating the complete resolution process.

It improves response times, reduces upstream queries, and helps DNS operate efficiently at scale.

What does TTL mean in DNS?

TTL stands for Time to Live. It specifies how long DNS data may normally remain fresh in a cache before it needs refreshing.

TTL is expressed in seconds.

What does TTL 300 mean?

A TTL of 300 represents five minutes.

It describes the normal cache lifetime of the relevant DNS data, not a guaranteed deadline for every application to observe a change.

What does TTL 3600 mean?

A TTL of 3600 represents one hour.

A resolver may normally reuse the associated cached RRset during that lifetime, subject to implementation behavior.

Is a lower DNS TTL always better?

No.

Lower TTLs can improve responsiveness to changes, but they also reduce cache reuse and can increase DNS query load.

The best value depends on operational requirements.

Does lowering TTL clear existing caches?

No.

Recursive resolvers with existing cached answers do not automatically receive the new TTL.

Lower TTLs should be configured ahead of planned migrations.

What happens when DNS TTL expires?

The cached data is no longer fresh for ordinary reuse.

The resolver generally needs a fresh answer, although Serve Stale may allow expired data to be returned under controlled failure conditions.

Why is my DNS still showing an old IP address?

The resolver may still have a valid cached RRset obtained before the change.

Other explanations include CNAME chains, split DNS, delegation problems, browser behavior, or a different resolver configuration.

What is negative DNS caching?

Negative DNS caching stores certain negative responses, including NXDOMAIN and NODATA results, to avoid repeatedly querying authoritative servers for unavailable data.

Its conventional behavior is defined by RFC 2308.

Why does a new DNS record still return NXDOMAIN?

A resolver may have cached an earlier response indicating the name did not exist.

It can continue using that negative cache entry until its applicable lifetime ends.

What is the difference between NXDOMAIN and NODATA?

NXDOMAIN indicates that the queried DNS name does not exist.

NODATA describes a name that exists but has no data of the requested record type.

Can a resolver return expired DNS records?

Yes, under specific circumstances.

RFC 8767 defines Serve Stale, which can allow expired cached information to be returned when fresh authoritative data cannot be obtained.

Can CNAME and A records have different TTLs?

Yes.

The CNAME RRset and the target’s A or AAAA RRset are separate DNS data and can have different cache lifetimes.

Does flushing Windows DNS clear Google or Cloudflare DNS?

No.

The Windows ipconfig /flushdns command clears the relevant local Windows DNS client cache.

It does not flush unrelated remote recursive resolvers.

Does DNS propagation always take 48 hours?

No.

There is no fixed global propagation timer.

The observed transition depends on existing cached data, resolver behavior, TTL values, delegation, and application state.

Does a low TTL guarantee fast DNS failover?

No.

DNS TTL is only one part of failover time.

Health detection, authoritative updates, resolver caching, client behavior, and connection reuse can all affect recovery.

Conclusion

DNS caching is much more than storing an IP address for a fixed period.

A complete understanding requires several related concepts:

DNS resource-record sets and independent TTL values
Positive and negative caching
NXDOMAIN and NODATA responses
SOA-based negative cache lifetimes
CNAME chains and multiple A records
Resolver prefetch and Serve Stale
Delegation changes and split-horizon DNS
Browser, operating-system, and recursive resolver caches
CDN and HTTP caching differences
DNS migrations, failover, and application behavior

The most important principle is that DNS TTL controls the normal freshness lifetime of cached DNS information; it is not a global countdown that forces every DNS resolver on the Internet to update at exactly the same moment.

When DNS changes appear inconsistent, avoid guessing. Query specific recursive resolvers, compare authoritative results, inspect the relevant RRsets and TTL values, and distinguish caching problems from delegation or application issues.

For further reading, explore DNS Explained for foundational concepts, DNS Record Types Explained for individual record types, and Linux Network Tools Guide for command-line diagnostic techniques.

To understand how name resolution fits into the wider networking stack, continue with TCP/IP Explained and Computer Networking Explained.