DNS and TTL

How long visitors keep reaching the old address after a change, and what a short TTL costs.

On the roadmap:Beginner · step 2: How the web works

Starterabout 10 min6 experiments

Experiments

New here? A few short steps show what happens, one at a time.

Settings

TTL on the record60 min

The TTL was lowered to 30 seconds ahead of the change

Resolvers that obey the TTL100%

Resolvers caching the record2,000

Each resolver is assumed to have fetched the record at a random time before the change. Ones that ignore the TTL are assumed to keep it for at least an hour.

Half moved after

30 min

Last one moved after

60 min

Lookups a day

48,000

TTL

60 min

With a TTL of 60 min, half the resolvers have the new address after 30 min and the last one after 60 min. The price of a short TTL is 48,000 lookups a day from 2,000 resolvers.

Visitors still sent to the old address

share of resolvers still on the old address

Still on the old address

Each resolver lets go of the old address when its cached copy expires. The line falls steadily because the copies were fetched at random moments, and any resolver that ignores the TTL holds it up.

The same change, every TTL

Half moved	All moved	Lookups a day
16 s	30 s	5,760,000
30 s	60 s	2,880,000
3 min	5 min	576,000
8 min	15 min	192,000
30 min	60 min	48,000
3.0 hours	6.0 hours	8,000
12.2 hours	24.0 hours	2,000

In plain words

DNS turns a name into an address, and caches the answer for a time the record's owner sets, the TTL. After you change an address, every resolver that cached the old one keeps sending visitors there until its copy expires. A short TTL makes changes quick and costs more lookups; a long one is cheap and slow to change.

Why it matters

Failover, migrations and traffic shifting often depend on DNS, and the TTL decides how fast they take effect. Teams find out the TTL was a day long at the worst moment. Here you can see the cost on both sides and practise the usual fix, which is to lower the TTL before you need to move.

How real systems do it

The simulation is a simplified model. Here is what production systems add or do.

Route 53, Cloudflare and other managed DNS services let you set the TTL on each record, with common values from 60 seconds to a day. Health-check based failover only works as fast as the TTL lets clients forget the failed address.
Some resolvers and operating systems cache longer than the TTL, and browsers and runtimes such as Java's JVM have been known to cache a lookup for much longer or forever by default. A DNS change is never quite instant.
Cloudflare and other CDNs hide the problem by using the same address for your site and moving traffic behind it, which changes the origin without changing the DNS record at all.
Anycast and load balancers do the failover behind a stable address instead of relying on clients to refresh, and are preferred where seconds matter.