Understanding DNS TTL: Why a Wrong Value Can Lock You Out for 48 Hours

What is TTL?

TTL stands for Time to Live. It is a value attached to every DNS record that specifies how many seconds a resolver is allowed to cache the record before it must fetch a fresh copy from the authoritative name server.

When you set an A record with a TTL of 3600, you are telling every DNS resolver in the world: "Cache this answer for one hour. After one hour, discard it and ask my nameserver again."

How DNS caching works across the internet

The DNS resolution chain involves multiple levels of caching:

1. Browser cache — Modern browsers cache DNS responses for a short period (usually 60 seconds or less), independent of the TTL
2. Operating system cache — The OS resolver caches responses according to the TTL value
3. ISP / Public resolver cache — The DNS resolver your computer queries (1.1.1.1, 8.8.8.8, or your ISP's resolver) caches records for the full TTL duration
4. Recursive resolvers worldwide — Every resolver that has previously looked up your domain caches the answer for the TTL duration

When you change a DNS record, the old value remains cached at all these levels until the TTL expires. You cannot force remote resolvers to flush their cache.

Common TTL values and what they mean

• 60 — 1 minute. Used for very dynamic records or during active migrations. High load on nameservers.
• 300 — 5 minutes. Good for pre-migration lowering and monitoring scenarios.
• 900 — 15 minutes. A reasonable balance between propagation speed and nameserver load.
• 3600 — 1 hour. A safe default for most records in normal operation.
• 86400 — 24 hours. Fine for stable records like NS and MX that rarely change.
• 172800 — 48 hours. The classic "registrar default" that causes lengthy propagation delays.

The right approach before a DNS migration

The most common TTL mistake is changing a record with a high TTL and then wondering why the change has not propagated. The correct sequence for any DNS migration is:

1. Lower the TTL in advance. At least 24 hours before the migration (ideally 48 hours), lower the TTL on the records you plan to change to 300 seconds (5 minutes). This gives the old high-TTL values time to expire from caches worldwide.
2. Wait. Do not make the actual record change yet. Wait for the current TTL to expire — if it was 86400, wait 24 hours before any remaining cache can serve the old TTL to new resolvers.
3. Make the change. Update the record to the new value. Because the TTL is now 300 seconds, propagation will complete in approximately 5 minutes for most resolvers.
4. Verify. Confirm the new value is resolving correctly from multiple geographic locations using tools like dig or an online DNS propagation checker.
5. Raise the TTL again. Once the migration is stable, raise the TTL back to 3600 or higher to reduce resolver load and improve performance.

TTL recommendations by record type

• A records: 3600 (1 hour) in normal operation. Lower to 300 before migrations.
• MX records: 3600–86400. MX records change infrequently and benefit from longer caching. Lower to 300 before changing mail providers.
• TXT records (SPF, DMARC, verification): 3600. These change occasionally during initial setup. 300 during setup, 3600 once stable.
• CNAME records: 3600. Same approach as A records.
• NS records: Set by your registrar. Typically 86400. Do not attempt to lower these — registrars often enforce their own minimums and the process of changing nameservers involves special handling.

Common TTL pitfalls

• Forgetting to lower TTL before a migration. The most common mistake. Results in slow propagation and split-brain scenarios where some users see old records and some see new ones.
• Setting TTL to 0. Some DNS providers interpret 0 as "do not cache at all." While technically valid in the RFC, many resolvers ignore this or enforce a minimum (usually 30–60 seconds). Very low TTLs create significant nameserver load.
• Not raising TTL after a migration. Leaving TTL at 300 permanently creates unnecessary load on your nameservers — every resolver worldwide re-fetches the record every 5 minutes.
• Changing NS records expecting fast propagation. NS record changes are handled specially by registrars and the root nameservers. The process is slower and more complex than regular DNS changes, regardless of the TTL you set.