DNS TTL Explained: Caching, Propagation, and Best Values
DNS TTL explained: a DNS record's time to live is the number of seconds a recursive resolver may reuse that answer from cache. A longer TTL usually reduces repeat lookups but keeps old data around longer; a shorter TTL makes planned changes easier, at the cost of more DNS queries.
DNS TTL explained: what the number controls
TTL is attached to a DNS resource record such as an A, AAAA, CNAME, MX, or TXT record and is measured in seconds. In the wire format specified by RFC 1035, a resolver uses it to decide when its cached copy is no longer fresh.
It is a cache-lifetime limit, not a promise that every visitor refreshes together. Resolvers can have different cache ages, discard data earlier, or apply local limits. TTL is set on a record or record set, not as one timer for the whole domain.
Do not confuse DNS TTL with the TTL or hop limit in an IP packet. DNS TTL times cached name data; the packet field counts network hops. HTTP and CDN caches have separate timers, so changing DNS TTL does not purge stored page content.
How a resolver uses DNS TTL
Suppose an authoritative server answers www.example.com A 203.0.113.20 with a TTL of 3600. A recursive resolver can reuse that answer for up to one hour, so a later request reaching the same resolver may avoid another authoritative lookup.
- The browser or operating system checks local information, including its cache and sometimes a hosts file.
- The device asks its configured recursive resolver, often supplied by a router, ISP, workplace, VPN, or DNS service.
- The resolver returns a usable cached answer, including its remaining TTL, or obtains fresh data from authoritative DNS.
Worked example: a resolver caches an old address at 09:00 with a 3600-second TTL. You change it at 09:25, leaving 2100 seconds, or 35 minutes, in that cache window. Lowering the published TTL to 300 seconds then cannot rewrite the old item.
If www is a CNAME, the alias and its target's A or AAAA answer can have separate lifetimes. A nameserver move also involves NS delegation, not just an A record.
What DNS TTL should you use?
There is no universal best value. Choose the longest cache window you can tolerate when a record changes, then account for resolver load, provider limits, DNSSEC, and failover needs. These are starting points, not guarantees; compare AWS Route 53's guidance with the NIST guide. For a migration example, Cloudflare's preparation guide uses 300 seconds as a common short value.
| Situation | Starting point | Decision to make |
|---|---|---|
| Stable website, mail, or verification record | 3600–86400 seconds | Prefer fewer lookups if you can tolerate a longer change window. |
| Planned migration or address change | 300 seconds, or the provider's minimum | Lower it before the change, wait for the old window to age out, then update. |
| Health-checked failover or frequent routing changes | 60–120 seconds where supported | Test resolver behavior and accept more queries, traffic, and possible cost. |
| New or deleted name returning NXDOMAIN | Inspect the SOA negative-cache settings | Do not assume the new record's TTL controls the cached “does not exist” answer. |
A very low value can increase query traffic and make an outage more visible. Zero is a special case and is usually a poor default; use a staged change plan instead.
Why a DNS change looks stuck
“Propagation” is not one global update. Resolvers refresh when their cached answer expires, while delegation, CNAME targets, local caches, and negative responses can have separate timers. A fixed hours-long estimate is not a rule for every record.
| Symptom | Likely cause | Next check or fix |
|---|---|---|
| Old address after lowering TTL | The old answer was cached first. | Query the authority and wait for the old remaining TTL; a later lower value is not retroactive. |
New hostname returns NXDOMAIN | A resolver cached a negative answer. | Check the authority and SOA negative TTL. Waiting may be required; a local flush cannot clear an ISP resolver. |
| Resolvers return different addresses | Their cache ages or policies differ. | Compare the same type at the authority and at two recursive resolvers. |
| Everything lags after a nameserver move | Parent NS data is cached, or the authorities disagree. | Verify the NS set and keep old and new services working during the change. |
RFC 2308 defines negative caching for NXDOMAIN and NODATA. Cloudflare's DNS guidance explains why lowering a new record's TTL does not remove an older negative entry. You can flush your device's DNS cache as a local test, after checking the authority.
How to check the TTL on Windows, macOS, Linux, Android, and iPhone
Settings show which resolver your device uses; a DNS query shows the TTL for a record. Use the exact record type you are troubleshooting and replace the example domain.
Windows 11
Open Start > Settings > Network & internet, choose Wi-Fi or Ethernet, select the network, then use IP assignment > Edit. In PowerShell run Resolve-DnsName example.com -Type A -DnsOnly; the result includes a TTL column. Add -Server <resolver-ip> to compare a resolver. See Microsoft's DNS client guide.
macOS
Open Apple menu > System Settings > Network, select the service, then Details > DNS. In Terminal run dig +noall +answer A example.com; the second column is the remaining TTL. See Apple's Mac DNS settings guide.
Linux
Menus vary by distribution. Run resolvectl status when systemd-resolved is in use, then dig +noall +answer A example.com. Compare a resolver with dig +noall +answer A example.com @<resolver-ip>, or query the authority with dig +noall +answer A example.com @<authoritative-ns>.
Android
Open Settings > Network & internet > Private DNS. This selects a provider but does not display a record TTL. Menu names vary by manufacturer; search Settings for “Private DNS” if needed. Google's Android guide confirms its scope.
iPhone and iPad
For connected Wi-Fi, open Settings > Wi-Fi > Info, then tap Configure DNS. This changes the Wi-Fi resolver, but iOS has no universal TTL readout. Use a trusted browser diagnostic or run dig on a computer. See Apple's iPhone Wi-Fi guide.
A quick self-test with Loqmi
- Open Loqmi's IP tool. If it loads while one named site fails, only Loqmi's name is confirmed.
- Run the Windows or
digcommand forloqmi.com, note the resolver and TTL, and repeat after one resolver change. - Use Loqmi's speed test to compare throughput and latency. It can separate a slow link from lookup trouble, but cannot reveal authoritative TTL.
A safe process for changing TTL
- Identify the active authoritative nameservers and exact record.
- Record its TTL. For a planned migration, lower it before the address change and wait out the previous cache window; the new value is not retroactive.
- Keep old and new destinations working during the overlap.
- Change one record, then query the authority and recursive resolvers for the relevant A, AAAA, CNAME, MX, or NS data.
- After verification, raise the TTL to a value your change schedule can tolerate.
For background, see how DNS works. For device-side changes, see how to change a DNS server; that does not expire another operator's cache.
Key takeaways
- DNS TTL is a cache-lifetime limit in seconds, not an IP packet hop count and not a CDN content timer.
- Long TTLs favor cache hits and stability; short TTLs favor quicker planned changes and failover.
- Lowering a TTL after an answer was cached does not shorten that older cache entry.
- NXDOMAIN has its own negative-caching path, and local cache flushing cannot clear remote resolvers.
- Check the authoritative server, the recursive resolver, and the exact record type before deciding what to fix.
Frequently asked questions
Does DNS TTL affect website loading speed?
Only the name-lookup part of loading. A cached answer can avoid a resolver round trip, while an expired answer may require a fresh lookup. TTL cannot increase your connection's download capacity or make a slow server faster. If you compare DNS settings, test the same sites on the same network and separate lookup delay from page delivery time.
Why do DNS checkers show different TTL values?
Each checker may query a different recursive resolver, and those resolvers can have cached the answer at different times. A value shown in a DNS dashboard is the published TTL; a query response usually shows the remaining time in that resolver's cache. Compare the same record type and query the authoritative nameserver when timing matters.
Is DNS TTL the same as IP packet TTL?
No. DNS TTL is a cache lifetime for a resource record, measured in seconds. IP packet TTL, also called hop limit for IPv6, is a hop counter in a packet header. DNS TTL affects when a resolver asks for fresh name data; packet TTL affects how far a packet can travel before being discarded.
What should I do if a new record still returns NXDOMAIN?
First query the authoritative nameserver to confirm that the record exists in the active zone and that the hostname is spelled correctly. If the authority is correct, a recursive resolver may still hold a negative answer from before the record was created. Check the zone's SOA negative-cache settings, then wait for that cached response to expire.
Sources
- RFC 1035: Domain Names - Implementation and Specification
- RFC 2308: Negative Caching of DNS Queries
- AWS Route 53: Best practices for DNS
- Cloudflare Learning Path: DNS migration preparation
- Microsoft Learn: Essential Network Settings and Tasks in Windows
- Microsoft Learn: Troubleshoot DNS Client Name Resolution Issues
- Apple Support: Change DNS settings on Mac
- Android Help: Manage advanced network settings on your Android phone