DNS TTL: Why Some Users Still Reach the Old Server

After changing an IP address in a DNS dashboard, some users may still reach the old server. The save operation has not necessarily failed: resolvers may retain cached answers. TTL explains part of this behavior, but is not a countdown shared by the entire internet.

This article covers address-record changes for existing names. It is not a nameserver migration guide and does not replace data synchronization or HTTPS checks.

1. What TTL describes

Cloudflare's DNS documentation describes TTL as a record's cache lifetime. A value of 300 means 300 seconds. DNS TTL is not the IP packet hop limit, nor the browser cache lifetime of HTML, images or API responses.

An authoritative server publishes the administrator's answer; recursive resolvers retrieve and cache answers for subsequent queries. Resolvers that retrieved data at different times can have different remaining lifetimes.

2. Lowering TTL does not revoke old answers

Suppose a resolver obtains the old IP at 09:00 with a 3,600-second TTL. At 09:10 the administrator lowers TTL to 300. The already-cached answer receives no recall instructing it to expire within five minutes. Under ordinary caching behavior, it can remain usable until roughly 10:00.

For a planned move, lower TTL in advance and allow a buffer based on the previous value. Do not promise that everyone updates exactly five minutes after choosing 300. Client, resolver and intermediary behavior can affect what is observed.

3. Check three different layers

A green result from one DNS-checking website cannot establish that every user has switched. Record query time, name, record type and resolver. A and AAAA require separate checks even for the same hostname.

4. Missing answers can be cached too

RFC 2308 specifies negative caching for answers such as nonexistent names or missing record types, with lifetime information tied to SOA. Creating a name after it previously returned a negative answer does not guarantee immediate success through every resolver.

Distinguish updates to existing names from creating new ones. The new A record's TTL alone cannot explain a cached NXDOMAIN. Nameserver, delegation or DNSSEC changes also require their own investigation.

5. A controlled address-change checklist

1. Record existing A, AAAA or relevant CNAME chains, TTLs and ownership.
2. Check the target with the intended hostname, certificate and data before cutover.
3. Where authorized, lower TTL early and allow for the old lifetime.
4. Decide how writes are handled while clients may reach either server.
5. Change the identified records and observe authoritative answers, resolvers and application logs.
6. Maintain rollback and evidence-based criteria for retiring the old server.
7. After stabilization, review the operating TTL and document the change.

Behind a proxy or CDN, public DNS may identify the proxy rather than the origin. Changing that platform's origin is another configuration layer. Establish the actual connection path before editing records.

6. A short TTL does not create failover

A shorter lifetime can support faster updates under suitable conditions. It does not detect failures, choose a backup server or guarantee consistent data. Longer lifetimes can reduce resolver queries; choose according to change requirements and operating needs rather than assuming one universal optimum.

Treat a DNS cutover as a layered service change. Cache knowledge sets expectations; endpoint checks, data handling and a rollback plan control its impact on users.