DNS TTL Explained: What It Is and How to Set It

TTL stands for Time to Live. In DNS, it's the number of seconds a resolver is allowed to cache a DNS record before it must discard that record and fetch a fresh copy from the authoritative nameserver. TTL is set on every DNS record individually and directly controls how quickly changes to those records spread across the internet.

How TTL Works

When a resolver fetches an A record with a TTL of 3600, it caches that record for 3600 seconds, one hour. During that hour, every user whose query reaches that resolver gets the cached answer without the resolver needing to contact your nameservers again. When the hour expires, the cached record is discarded. The next query after expiry triggers a fresh lookup from your authoritative nameserver.

TTL counting starts from the moment the resolver caches the record, not from the moment you make a change. If a resolver cached your A record with a 24-hour TTL 23 hours ago, it will refresh in one hour. If it cached it 1 hour ago, it won't refresh for another 23 hours.

This caching happens independently at every layer: your ISP's resolver, public resolvers like 8.8.8.8, your router's DNS forwarder, your operating system's stub resolver, and sometimes the browser. Each layer applies the TTL independently from when it first fetched the record.

Reading TTL in DNS Output

When you run a dig query, the TTL is shown in the answer section. The number represents the seconds remaining on the cached record from the perspective of the resolver you queried:

$ dig yourdomain.com A

;; ANSWER SECTION:
yourdomain.com.  3542  IN  A  93.184.216.34

The 3542 here means this resolver's cached copy expires in 3542 seconds. The original TTL was 3600 (one hour) and 58 seconds have passed since it was cached. To see the authoritative TTL without caching effects, query the nameserver directly:

dig @ns1.hosted-server.net yourdomain.com A

Common TTL Values and When to Use Them

• 300 (5 minutes): low TTL. Use when you're about to make a DNS change or need fast failover. Records with a 5-minute TTL mean most resolvers will have the new value within 5 to 10 minutes of a change. Increases the number of queries hitting your nameservers.
• 3600 (1 hour): a sensible default for most records on a stable site. Balances caching efficiency with a reasonable window for changes to take effect.
• 14400 (4 hours): common default used by many registrars. A practical middle ground for records that rarely change.
• 86400 (24 hours): high TTL. Use on records that essentially never change, for example, MX records pointing to a long-established email provider, or NS records. Significantly reduces query load on your nameservers and improves response times from cache.

The Pre-Migration TTL Workflow

TTL matters most when you're about to make a DNS change. If your A record has a TTL of 86400 when you update it, resolvers that cached it recently will serve the old IP for up to 24 hours. To control the propagation window, lower your TTL well before any planned change.

1. At least 24 to 48 hours before your DNS change, lower the TTL on the relevant records to 300 seconds.
2. Wait the full duration of the original TTL. This ensures all resolvers that had cached the old TTL value have now refreshed and are honouring the new 5-minute TTL.
3. Make the DNS change (update your A record or nameservers).
4. Within 5 to 10 minutes, the change will be live for the vast majority of visitors worldwide.
5. After you've confirmed the migration is stable and working, raise the TTL back to 3600 or higher.

Skipping step 2 is the most common mistake. If you lower the TTL to 300 and make the change immediately, resolvers that cached the old 86400 TTL 12 hours ago will still serve the old record for another 12 hours, regardless of the new 300-second TTL, because they haven't re-fetched the record yet.

TTL Does Not Mean Instant

Even with a TTL of 300, propagation isn't instant. A few reasons:

• Non-compliant resolvers: some ISP resolvers extend TTLs beyond the specified value, continuing to serve cached records longer than they should.
• Negative caching: NXDOMAIN responses (domain not found) are also cached with a negative TTL. If a resolver cached a failed lookup, it may continue returning NXDOMAIN even after the record is created, until that negative cache expires.
• Browser and OS caches: these apply their own caching on top of the resolver's, with minimums that can exceed the DNS TTL in some implementations.

In practice, a 300-second TTL means the change will be visible to most users within 5 to 15 minutes, with stragglers possibly taking up to an hour.

Where to Set TTL

TTL is configured in your DNS zone, wherever your DNS is hosted. Log in to your DNS provider (your registrar, hosting provider, or a third-party like Cloudflare) and edit the specific record. Most interfaces show a TTL field alongside the record name and value.

Some providers use human-readable dropdowns (1 hour, 4 hours, 1 day, Auto) rather than raw seconds. Cloudflare's "Auto" TTL sets records to 300 seconds when the proxy is off, and manages TTL automatically when proxied. For non-proxied records where you need control, set an explicit value.

The minimum TTL most providers allow is 60 seconds (1 minute). Very few legitimate use cases require sub-minute TTLs, and some resolvers will ignore TTLs below their own minimum floor of 30 seconds.

SOA TTL: The Zone-Level Default

Every DNS zone has an SOA (Start of Authority) record that includes a default TTL value. This TTL applies to any records in the zone that don't have their own TTL specified. It also controls the negative caching TTL, how long resolvers cache "this record doesn't exist" responses. When setting up a new zone, the SOA default TTL is worth reviewing; an inherited value of 86400 can slow down debugging when you're actively adding records.