Every DNS record carries a number called TTL, time to live. It is the instruction that tells caches how long they may keep an answer before asking again. Get it right and DNS changes during a migration take effect within minutes. Get it wrong and half your visitors reach the old server for a day. The DNS basics guide mentions TTL in passing. This guide is the deeper version: how the caching chain really behaves, which values to pick, and a timeline for changes.
What TTL actually is
TTL is measured in seconds and is set per record set (all A records for a name share one TTL in practice). When a recursive resolver, such as your ISP's or a public one like 1.1.1.1 or 8.8.8.8, looks up www.example.com, it asks the authoritative nameserver and receives the records plus a TTL, say 3600. The resolver stores the answer and serves it to everyone who asks for the next 3600 seconds, counting down. When the countdown reaches zero, the entry expires and the next query triggers a fresh lookup.
You can watch this happen. Run the same query twice against a public resolver:
dig www.example.com A @1.1.1.1www.example.com. 2874 IN A 203.0.113.10The second column is the remaining TTL in the resolver's cache, not the configured value. Run it again a minute later and the number will be about 60 lower. Ask the authoritative server directly and you see the configured value:
dig +short NS example.com
dig www.example.com A @ns1.example-dns.comThe authoritative answer always shows the full TTL, because it is the origin of the data.
Where caching happens
TTL is respected by many layers, and each one can hold a stale answer:
- The recursive resolver (ISP, corporate, public). This is the one TTL is meant to control.
- The operating system stub resolver and cache. Windows, macOS and systemd-resolved cache lookups locally.
- The browser. Chrome and others keep an internal DNS cache, typically for a short time regardless of TTL, and also hold open connections to the old IP.
- Applications and runtimes. Some long-running services resolve once at startup and never again. Java's DNS cache behavior, for example, has depended on security manager and configuration settings, so check the platform's docs for any service where a stale address would hurt.
- Routers and home gateways that act as DNS forwarders.
Some resolvers also ignore low TTLs. A small number clamp very short TTLs to a minimum floor, and some enforce a maximum cap. Do not assume a resolver follows your numbers to the second. That is why propagation is "up to the old TTL plus a margin", not exactly the TTL. The DNS propagation guide covers what you will see from different locations.
Negative caching
Resolvers also cache failure. If a name does not exist (NXDOMAIN) or a record type is missing (NODATA), the answer is cached for a time taken from the SOA record's minimum field and the SOA's own TTL, whichever is lower. If you query a hostname before you create the record, resolvers may remember "no such name" for up to that period, which explains why a freshly added record is "not there yet" for some people. Check the zone's SOA values:
dig +short SOA example.comns1.example-dns.com. hostmaster.example.com. 2026100501 7200 3600 1209600 300The last number, 300 here, is the negative-caching value. See the DNS records cheat sheet for what each SOA field does.
Typical TTL values
There is no universal right answer, but there are sensible defaults:
| Record or situation | Suggested TTL | Why |
|---|---|---|
| Stable A/AAAA for a website | 3600 (1 hour) to 14400 (4 hours) | Fewer queries, fast enough to change |
| Records you plan to change soon | 300 (5 minutes) | Quick cutover |
| During an active migration or incident | 60 to 300 | Minimal stale time |
| MX records | 3600 to 86400 | Mail systems retry; stability matters more |
| NS records at the registrar (delegation) | Set by the registry, often 86400 or 172800 | You cannot control these from your DNS panel |
| TXT for SPF, DKIM, verification | 3600 | Rarely changes |
| CNAME to a vendor | 3600 | Follows the vendor's guidance |
| Failover or load-balancing records | 30 to 60 | Health-based DNS needs fast reaction |
| CAA | 3600 to 86400 | Rarely changes |
Check your provider's allowed minimum. Many DNS hosts enforce a floor of 30, 60 or 300 seconds on lower plans, and "automatic" TTL on some platforms means a fixed short value that you cannot tune.
The trade-offs of low TTL
A low TTL is not free:
- More queries to your authoritative servers. If you pay per query or you self-host DNS, a 30-second TTL on a busy name multiplies the load.
- Slightly slower first lookups for users whose cache has expired, because they wait for a fresh resolution. This is usually a few dozen milliseconds, but it adds up for pages that pull in many hostnames.
- Less resilience to DNS outages. With a long TTL, a resolver can keep answering from cache while your DNS provider is down. A very short TTL removes that cushion, which is one reason a persistent 60-second TTL on everything is not recommended. Some resolvers serve stale data during upstream failures, but you should not depend on that.
A common compromise: keep a long TTL (an hour or more) day to day, and lower it temporarily around planned changes.
A planning timeline for DNS changes
Because caches hold the old answer until the old TTL expires, the lowering of TTL must happen before the change, by at least one old-TTL period.
- Find the current TTL of the record you will change. If it is 86400, you need a day of lead time.
dig +noall +answer www.example.com A @ns1.example-dns.com- Lower the TTL to 300 (or 60 if your provider allows) without changing the value. Note the time.
- Wait at least the old TTL (24 hours in the example). Only after that are all well-behaved caches holding records with the short TTL.
- Make the change to the new IP, target or provider. Lower the load on the old server by keeping it running and serving content.
- Verify from several places. Use the DNS checker to query multiple global resolvers, and use
dig @8.8.8.8anddig @1.1.1.1. Confirm the authoritative servers first, since they are the source of truth. - Keep the old server alive for at least the old TTL after the change, plus margin for stubborn resolvers. Many migrations finish at 99% in minutes and trail off for hours.
- Raise the TTL again to your normal value once everything is stable.
For a complete migration workflow, including copying files, databases and certificates, see migrate a website without downtime. If you are switching DNS providers, the sequence is slightly different and is covered in change nameservers without downtime.
Special cases
Nameserver changes. The NS records at your registrar are cached for the TLD's configured time, often 24 to 48 hours, and you cannot lower that. Copy all records to the new DNS host first and keep both sets of nameservers answering identically during the switch.
Email. Lower the TTL on MX records before moving mail, and keep the old mail system accepting messages during the overlap. Senders that cached the old MX will deliver there until it expires.
Records with CDNs or proxies. If your records are proxied by a CDN, the TTL visitors see is controlled by the CDN, not by what you type in the DNS panel. Cloudflare's proxied records, for example, use an automatic TTL, and origin changes take effect when you edit the origin because the public answer does not change.
Wildcard and CNAME chains. Each link in a CNAME chain has its own TTL, and the effective cache lifetime is bounded by the shortest link at each step. Delegating a name to a vendor's CNAME means you inherit the vendor's TTL for the final address.
TTL 0. Some panels accept 0. Behavior is not consistent across resolvers, so use a small positive value instead.
Checking what changed and when
Compare past and present records with the DNS history tool if you are investigating a change from the past. For ongoing protection, the uptime monitor includes DNS change alerts, so an unexpected record edit pages you instead of surprising you hours later. If you suspect a stale record is sending traffic to the wrong place, the website hosting checker shows where the site resolves right now.
अगले कदम
- Look up the TTLs on your records with the DNS checker and the authoritative servers with the nameserver lookup.
- Plan changes using how long does DNS propagation take.
- Turn on DNS-change alerts in the uptime monitor.
- Read the DNS records cheat sheet for the SOA fields that control negative caching.
सामान्य प्रश्न
Why do some users still see the old site after the TTL passed?
Some resolvers extend or clamp TTLs, browsers keep their own caches and open connections, and some applications resolve names only at startup. Clearing local caches or waiting a little longer usually resolves it.
What TTL should I use for a normal website?
Between 3600 and 14400 seconds is a sensible default. Lower it to 300 a day before a planned change, then raise it again afterward.
Does a low TTL hurt SEO or speed?
It does not affect rankings directly. It can add a small delay on first lookups after cache expiry, and it increases query volume, so avoid very low values as a permanent setting.
Can I flush the DNS cache everywhere?
You can flush your own machine (ipconfig /flushdns on Windows, sudo resolvectl flush-caches on Linux with systemd-resolved) and some public resolvers offer a cache purge page. You cannot flush every resolver on the internet, which is why lowering TTL beforehand matters.
Get notified when this guide updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.