TTL in DNS: What It Means and Why It Matters

Every DNS record has a TTL — Time To Live. It is one of the most misunderstood settings in DNS, and getting it wrong is usually the reason why DNS changes take longer to propagate than expected.

What Is DNS TTL?

TTL is a number measured in seconds that tells DNS resolvers how long to cache a record before re-querying the authoritative nameserver.

When a resolver looks up your A record and finds a TTL of 3600, it stores that answer for 3600 seconds (1 hour). For the next hour, it serves the cached answer to anyone who asks — without checking back with your nameserver.

This caching is what makes DNS fast globally. Without it, every DNS query would require a live query to your authoritative nameserver, which would be slow and put massive load on nameservers.

How TTL Affects Propagation

TTL directly bounds how long DNS propagation takes. If your A record has a TTL of 86400 (24 hours) before you change it, some resolvers will continue serving the old value for up to 24 hours after you make the change — because they cached it with a 24-hour lifetime.

The general rule: maximum propagation time ≈ old TTL value.

Common TTL Values

TTL	Seconds	When to Use
300	5 minutes	During planned migrations
3600	1 hour	Normal records (recommended default)
14400	4 hours	Stable records, rarely changed
86400	24 hours	Very stable records (MX, NS)

How to Lower TTL Before a Migration

This is the most important TTL technique: lower your TTL 24 hours before making DNS changes, not at the same time.

Why 24 hours? Because you need to wait long enough for the old (high) TTL to expire from all caches before the new (low) TTL takes effect globally.

Step-by-step migration process:

1. 24+ hours before migration: Lower TTL to 300 seconds on records you will change.
2. Wait 24+ hours for the old TTL to expire from all caches.
3. Make your DNS change (new A record, new MX, etc.).
4. Wait 5-10 minutes — with TTL=300, this is enough for most resolvers.
5. Verify with the DNS Propagation Checker (Tools → DNS Propagation).
6. After migration is confirmed stable: Raise TTL back to 3600 or higher.

Skipping step 2 is the most common migration mistake. If you lower TTL and change the record simultaneously, some resolvers still have the old TTL cached and will hold onto the old value for its full duration.

TTL for Different Record Types

Different record types have different change frequency profiles:

A records: 3600 (1 hour) normally. Lower to 300 before hosting migrations.

MX records: 3600-14400. Email providers often recommend 3600. Don't set too low — email servers queue messages and retry, so a briefly incorrect MX just causes delays, not permanent failures.

TXT records (SPF, DKIM, DMARC): 3600. These change infrequently.

NS records: Often 86400 or higher. Set by your registrar when you delegate DNS. Not something you typically change.

CNAME records: 3600. Same as A records.

The Minimum TTL and SOA

The SOA (Start of Authority) record has a minimum TTL field that sets the floor for negative caching — how long a "record not found" response is cached. This is separate from individual record TTLs. Typically set to 300-3600 seconds.

Common TTL Mistakes

Setting TTL=0: No caching at all — every query hits your nameserver. This puts enormous load on your nameservers and increases DNS latency for every visitor. Only use temporarily during critical failover scenarios.

Never lowering TTL before migrations: Results in 24+ hour propagation windows instead of 5 minutes.

Setting very high TTL on A records: A TTL of 86400 on your A record means any hosting change or failover takes up to 24 hours to propagate globally.

Inconsistent TTLs: Some providers set different TTLs on different A records for the same name. This can cause unpredictable resolver behavior.

Checking Your Current TTLs

In ElasticDomain's DNS tab, every record shows its TTL value alongside the record data. You can see at a glance which records are set with short vs long TTLs and plan migrations accordingly.