If you have ever changed a DNS record and wondered why the old website kept showing up for hours afterward, the answer is almost certainly TTL. Time To Live is one of the most practical, most misunderstood settings in all of DNS, and getting it wrong can mean hours of downtime during a migration or a security incident you cannot remediate fast enough. This guide breaks down exactly what TTL is, how it works at every layer of the DNS resolution chain, how to read and set it correctly, and what values to use in different real-world situations.
What TTL Actually Means
TTL stands for Time To Live. In DNS, it is a numeric value attached to every single resource record in your zone file. The unit is seconds. That number tells every resolver and caching server in the world: "You may cache this answer for this many seconds. After that, throw it away and ask again."
So a TTL of 3600 means any resolver that fetches your A record can hold onto that answer for one hour before it needs to requery the authoritative nameserver. A TTL of 300 means five minutes. A TTL of 86400 means one full day.
TTL is not a propagation timer in the way most people imagine it. It does not push changes out to the world. It governs how long cached copies are considered valid. Once the timer expires, the next DNS query for that record will go all the way back to your authoritative nameserver and fetch the fresh value. Until then, every resolver that already cached the old answer will keep serving it.
Where TTL Lives in a DNS Record
In a raw zone file, TTL is the third field in each resource record line. Here is what a classic A record looks like:
Reading left to right: the name, the TTL in seconds, the class (IN for internet), the record type, and the data. Most DNS control panels hide this behind a friendly input box labelled "TTL" with a dropdown like "1 hour" or "5 minutes", but the underlying mechanism is always the same integer value stored with each record.
There is also a default TTL set at the top of the zone file using the $TTL directive. Individual records can override it, but any record without an explicit TTL inherits the zone default.
How TTL Flows Through the Resolution Chain
Understanding why TTL matters requires understanding what happens each time a browser makes a DNS request. There are at least three caching layers involved:
- Your operating system DNS cache — Windows, macOS, and Linux all cache DNS answers locally. They respect the TTL from the record but may impose their own minimum floors (Windows historically floors at 1 second; macOS honors the TTL closely).
- Your router or local DNS forwarder — Home routers and office DNS servers often cache records too. The TTL countdown continues from wherever in the chain the record was first fetched.
- Recursive resolvers — ISP resolvers, Google (8.8.8.8), Cloudflare (1.1.1.1), and others cache records according to the TTL. They will serve cached responses to every client querying them until the TTL expires, then re-fetch from the authoritative nameserver.
Here is the critical insight: each resolver starts its own TTL countdown from the moment it first caches the record. Google's resolver might cache your record with 3600 seconds left. Your ISP's resolver might have cached it 55 minutes ago and only has 300 seconds left. A user in Japan might be hitting a regional resolver that cached it 10 minutes ago. That is why "propagation" is not instant even when you lower the TTL — you are at the mercy of existing cache lifetimes that were set before you made the change.
Reading the Current TTL of Any Record
You can check the TTL of a live DNS record from the command line in seconds. The value returned is the remaining TTL — how many seconds are left before that resolver's cache expires.
On Linux or macOS, use dig:
That 2847 means this resolver cached the record 753 seconds ago and has 2847 seconds left on its copy. Run the same command 30 seconds later and you will see 2817 — the countdown is live.
On Windows, use nslookup or PowerShell:
To query the authoritative nameserver directly and see the full original TTL rather than a cached remainder, bypass recursive resolvers entirely:
You can also use our DNS Lookup tool to check TTL values from multiple vantage points worldwide without touching a terminal.
Common TTL Values and When to Use Each
There is no universally correct TTL. The right value depends entirely on how often the record changes and how fast you need changes to take effect.
60 seconds (1 minute)
Rarely appropriate for production. Some providers impose a minimum of 60 seconds. Use this only when you are actively debugging a live DNS change and need near-real-time propagation. Be aware that ultra-low TTLs dramatically increase query load on your authoritative nameservers and can trigger rate limiting on some DNS hosting platforms.
300 seconds (5 minutes)
The standard "low TTL" used before a planned migration. Change your TTL to 300 at least 48 hours before you need to make the actual record change. This ensures that by the time you swap the A record or CNAME, the maximum anyone can be stuck on the old value is five minutes.
3600 seconds (1 hour)
A solid default for most records that change occasionally. Good for A records on stable servers, MX records, and SPF TXT records. Balances reasonable propagation speed against resolver load.
86400 seconds (24 hours)
Appropriate for records that almost never change: NS records, CAA records, DMARC TXT records, and similar infrastructure-level entries. Higher TTLs improve resolution performance for end users because resolvers cache the answer longer and avoid repeated lookups.
SOA record negative TTL
The SOA record contains a separate value called the negative TTL (the last field). This controls how long resolvers cache negative responses — i.e., "this record does not exist." Keep negative TTL low (300 to 900 seconds) so that if you add a new subdomain, the "does not exist" answer cached by resolvers expires quickly.
The Pre-Migration TTL Lowering Trick
This is the single most important practical application of TTL knowledge. If you are moving a website to a new host, changing your mail server, or doing any DNS-impacting migration, follow this sequence:
- At least 48 hours before migration day, log into your DNS control panel and lower the TTL on the affected records to 300 seconds (5 minutes). Wait the full 48 hours — this ensures that every recursive resolver on earth has had a chance to expire its old cached copy of your 86400-second record and pick up the new short TTL.
- On migration day, make your actual DNS change (swap the A record, update the MX, etc.). Because the TTL is now 300 seconds, the worst-case delay for any user to see the new record is five minutes.
- After confirming the new setup is stable (24 to 48 hours later), raise the TTL back to 3600 or higher to reduce query load and improve performance.
Skipping step one is the most common cause of "my site was down for 24 hours after I migrated" complaints. The migration was fine — the old high TTL was the culprit.
How to Set TTL in Popular DNS Control Panels
Cloudflare
Log in at dash.cloudflare.com, select your domain, go to DNS > Records. Click Edit on any record. The TTL dropdown defaults to "Auto" (which Cloudflare sets to 300 for proxied records). For non-proxied records, expand the TTL dropdown and select a custom value or choose from the presets (2 minutes, 5 minutes, 1 hour, etc.).
AWS Route 53
In the Route 53 console, navigate to Hosted zones > your domain > Records. Select the record and click Edit record. The TTL field is a plain text box accepting seconds. AWS does not prevent you from entering very low values like 60, but the Route 53 pricing model charges per query, so very low TTLs on high-traffic records will increase your bill.
cPanel / WHM (shared hosting)
In cPanel, go to Domains > Zone Editor. Click Manage next to your domain. Each record row shows the TTL. Edit inline and save. Note that many shared hosts lock the TTL or set a minimum floor — contact support if you cannot change it below 3600.
GoDaddy
Log in, go to My Products > DNS next to your domain. In the records table, click the pencil icon on any record. The TTL dropdown offers presets from 30 minutes to 1 week. GoDaddy enforces a minimum of 600 seconds (10 minutes) on most account types.
Negative Effects of Getting TTL Wrong
TTL misconfigurations fall into two failure modes:
TTL set too high:- DNS changes take hours or days to propagate to all users.
- During a server emergency (a compromised server you need to take offline, a hosting provider going down), you cannot redirect traffic quickly.
- Certificate validation failures if you are using DNS-01 ACME challenges for SSL certificates and the challenge record takes too long to disappear.
- Dramatically increased query volume hitting your authoritative nameservers. For high-traffic domains this can become a cost and stability issue.
- Slower perceived DNS resolution for end users because resolvers cannot serve cached answers and must do full recursive lookups more frequently.
- Some authoritative DNS providers (free tiers especially) rate-limit or reject zones with TTLs below 60 seconds.
TTL vs. DNS Propagation: Clearing Up the Confusion
These two terms are often used interchangeably but they mean different things. Propagation refers to the time it takes for a DNS change to be visible to all users globally. TTL is the primary mechanism that determines propagation time, but it is not the only factor.
Other factors that affect propagation time include:
- Whether the resolver respects the TTL strictly or imposes a minimum cache time (some older ISP resolvers ignore low TTLs and cache for a minimum of 30 minutes).
- How quickly your DNS hosting provider replicates changes across its own anycast nodes after you save them in the control panel.
- Local OS and browser DNS caches that may hold records independently of resolver caches.
The practical takeaway: TTL is the lever you control. Lower it before a planned change, and propagation will be fast. Leave it high, and you are at the mercy of whatever was cached before you made the change.
Verifying Your TTL Changes Took Effect
After updating a record's TTL in your control panel, confirm the authoritative nameservers are serving the new TTL before you proceed with any migration:
If the authoritative server shows the new TTL, you are good — the change is live at the source. Recursive resolvers will start serving the new TTL as soon as their existing cached copies expire.
Remember: you cannot force recursive resolvers to flush their cache early (with limited exceptions like Cloudflare's cache purge for their own resolver). The old TTL has to naturally expire first. This is exactly why the 48-hour pre-migration window is not optional — it is the time required for existing high-TTL cached records to drain out of the global resolver population.
Quick Reference Summary
- TTL unit: seconds
- What it controls: how long resolvers cache DNS answers before requerying
- Default for stable records: 3600 (1 hour)
- Before a migration: lower to 300, wait 48 hours, then make the change
- After migration confirmed: raise back to 3600 or higher
- Check live TTL:
dig A example.com— the second column in the ANSWER SECTION - Check authoritative TTL: query your NS directly with
@ns1.yourprovider.com
TTL is a simple integer, but it has real consequences for how fast your DNS changes reach users and how resilient your infrastructure is during emergencies. Treat it as an intentional configuration choice rather than a field you leave at whatever the control panel defaulted to when you set up the zone.