Skip to content
Hosting Operations9 min read

DNS TTL Explained: 300s vs 3600s vs 86400s [2026]

Compare DNS TTL values to fix slow propagation or reduce query load. Learn which TTL fits migrations, static sites, and CDN configs.

Written by Abdul AbrorTechnical Hosting Support Engineer
Computer screen displaying code and text
On this page

TL;DR — Key takeaways

  • TTL is the number of seconds a DNS resolver caches your record before checking again; lower TTL means faster updates but more queries.
  • Use 300-600 seconds before migrations or IP changes, then raise to 3600-86400 after the change settles to reduce server load.
  • CDN and static sites can safely use 86400 (24 hours) or higher; mail servers and dynamic infrastructure need 300-3600 to handle failovers.
  • Propagation delay comes from old TTL values already cached, not the new TTL you just set—plan changes one old-TTL cycle ahead.

DNS TTL controls how long recursive resolvers cache your records before asking your nameserver again. Set it too high and an IP change takes a day to propagate. Too low and you flood your authoritative servers with queries.

In support tickets I handled, the most common mistake was changing a record and expecting instant propagation without lowering the TTL first. The resolver was serving a cached answer with 24 hours left on the clock. This guide compares the three most common TTL ranges—300, 3600, and 86400 seconds—so you can pick the right one for your situation and avoid the wait.

How DNS TTL Actually Works

When a recursive resolver like 8.8.8.8 or your ISP's DNS queries your domain, it receives the answer plus a TTL value in seconds. The resolver caches that answer and starts a countdown. A TTL of 3600 means the resolver will serve the cached record for one hour without contacting your nameserver again.

Once the timer hits zero, the resolver discards the cached copy and fetches a fresh record from the authoritative server. That's when any changes you made appear. The key detail: the TTL in effect when the record was cached determines how long the old answer survives, not the new TTL you set five minutes ago.

Check your current TTL with dig +noall +answer example.com or nslookup -type=any example.com. The number in the second-to-last column is the remaining cache time, counting down in real time if you run the command twice.

    TTL 300-600 Seconds: Pre-Migration and Active Failover

    A 5-10 minute TTL is the standard pre-change setting. Lower your TTL to 300 at least one old-TTL cycle before a migration—if your current TTL is 86400, lower it 24 hours ahead so the short TTL propagates first. Then make your IP or CNAME change and wait 5-10 minutes for global resolvers to pick up the new record.

    Permanent low TTL makes sense for active-active load balancing with health checks, where you need to pull a failed node out of DNS in under five minutes. Cloudflare's load balancer and Route 53 health checks both assume you're running TTL 60-300 in that scenario.

    The cost is higher query volume. If you serve 100,000 page views per day and each visitor triggers a DNS lookup, a TTL of 300 generates roughly 288 queries per record per day (86400 ÷ 300). A TTL of 86400 generates one query per record per day per resolver. Multiply by the number of unique resolver IPs hitting your site.

    • Use 300 seconds starting 24-48 hours before any planned DNS change (server migration, IP swap, CDN switch)
    • Keep it at 300 permanently only if you run automated failover that must respond in under 5 minutes
    • Verify propagation with dig @8.8.8.8 example.com and dig @1.1.1.1 example.com after the change

    TTL 3600 Seconds: General-Purpose Balance

    One hour is the default TTL for most managed DNS providers and the sweet spot for records that change occasionally but not daily. It caps propagation delay at 60 minutes, which is acceptable for most maintenance windows, while cutting query load to 1/12 of a 300-second TTL.

    I recommend 3600 for A and AAAA records pointing to application servers, mail server MX records, and any infrastructure that might need a mid-day IP change during an outage. If your hosting provider moves your VPS to a new hypervisor, a one-hour wait is tolerable. A 24-hour wait is not.

    Raise your TTL back to 3600 after a migration settles. Leaving it at 300 indefinitely just burns nameserver quota and adds 200ms to the first page load for every visitor whose resolver's cache expired.

      TTL 86400 Seconds: Static Sites and CDN Origins

      A 24-hour TTL works well for records that never change. CDN CNAME targets, static site A records pointed at a long-term host, and parked domains can all use 86400 or even 604800 (one week). The IP behind a Cloudflare proxied record or a Netlify deploy never moves, so caching it for a day saves thousands of queries.

      The tradeoff is planning. If you need to change the record, lower the TTL to 300 first, wait 24 hours for the old 86400 TTL to expire globally, then make the change. Skip that step and some resolvers will serve stale data for another day.

      NS and SOA records often default to 86400 or higher because nameserver IPs rarely change. Lowering them doesn't help—NS lookups happen when resolvers query your domain for the first time or after the parent zone's TTL expires, which is controlled by your registrar, not your authoritative nameserver.

      • Safe for CDN CNAME records, static site hosts, and parked domains that won't move for months
      • Plan 24-48 hours ahead if you ever need to change the record—lower TTL first, then wait, then change
      • NS and SOA records default to 86400; lowering them has no practical benefit for most setups

      Why Propagation Takes Longer Than the TTL You Set

      The biggest source of confusion: you change a record, set TTL to 60, and still see the old IP two hours later. The reason is that some resolver cached your record yesterday when the TTL was still 86400. That resolver's cache won't expire for another 22 hours, regardless of what the authoritative nameserver says now.

      The new TTL only applies to queries made after you changed it. Any resolver that fetched the record before your change is still counting down the old TTL. This is why you lower TTL one full old-TTL cycle before the migration.

      Test propagation by querying different public resolvers. Run dig @8.8.8.8 example.com, dig @1.1.1.1 example.com, and dig @208.67.222.222 example.com (OpenDNS). If they all return the new IP, most of the internet has caught up. Your ISP's resolver or a corporate DNS filter might still be behind.

        Choosing the Right TTL for Each Record Type

        A records for app servers: 3600. MX records: 3600. TXT records for SPF and DKIM: 3600 unless you rotate keys often, then 1800. CNAME for a CDN that you control: 86400. CNAME for a third-party SaaS that might change endpoints: 3600.

        Mail servers deserve a stable TTL because mail delivery retries are slow. An MX record with TTL 300 doesn't speed up delivery; it just creates query noise. Set it to 3600 and lower it only if you're migrating to a new mail host.

        CAA records can use 86400 unless you frequently change certificate authorities. DMARC TXT records can also use 86400—policy changes are infrequent and a 24-hour delay is harmless. NS records default to 172800 (48 hours) and should stay there.

        • A/AAAA for application servers: 3600 (1 hour)
        • MX records: 3600, never lower than 1800
        • CDN CNAME or static site A record: 86400 (24 hours)
        • SPF/DKIM TXT: 3600, or 1800 if you rotate keys monthly
        • CAA, DMARC, DNSKEY: 86400 unless actively changing

        Step-by-Step: Lowering TTL Before a Migration

        Check your current TTL with dig +noall +answer example.com. Note the value—let's say it's 86400. Log in to your DNS provider (Cloudflare, Route 53, your registrar's panel) and edit the record. Change TTL to 300 and save.

        Wait 24 hours (or whatever your old TTL was). After that window, every resolver on the internet has either expired the old cache or fetched the new 300-second TTL. Now perform your migration: update the A record to the new IP, change the CNAME target, or swap the MX record.

        Wait another 5-10 minutes (the new TTL), then test from multiple resolvers. If the new IP appears everywhere, the migration succeeded. Wait 24 hours for traffic to stabilize, then edit the record again and raise TTL back to 3600 or 86400. You're done.

          Common Mistakes and How to Fix Them

          Mistake one: changing the record and the TTL at the same time. The new TTL doesn't help because resolvers are still serving the cached answer with the old TTL. Always lower TTL first, wait, then change the record.

          Mistake two: setting TTL to 60 permanently. It increases query costs and latency with no upside unless you run automated failover. Raise it back to 3600 after the change window closes.

          Mistake three: assuming 'propagation' is a fixed 24-48 hour delay. Propagation time equals the TTL that was in effect when the record was last cached. Control that by lowering TTL ahead of time. Testing from your local machine isn't enough—your ISP's resolver might be slow. Query 8.8.8.8 and 1.1.1.1 directly to bypass local cache.

            Quick troubleshooting checklist

            • Check current TTL with dig +noall +answer example.com or nslookup -type=any example.com
            • Lower TTL to 300 seconds at least 24-48 hours before any DNS change (migration, IP swap, failover test)
            • Wait one full old-TTL cycle after making the change, then verify with dig @8.8.8.8 and dig @1.1.1.1
            • Raise TTL back to 3600+ once the change is stable to reduce query volume and cost
            • Document TTL choices in your infrastructure repo so future engineers understand the reasoning

            FAQ

            What is DNS TTL and why does it matter?

            DNS TTL (Time To Live) is the duration in seconds that DNS resolvers cache a record before querying the authoritative server again. A 300-second TTL means resolvers will use the cached answer for 5 minutes, then fetch a fresh copy. Lower TTL speeds up propagation when you change an IP or CNAME, but increases query load on your nameservers. Higher TTL reduces traffic and cost but delays updates.

            How long does DNS propagation actually take?

            Propagation is controlled by the old TTL value already cached across the internet, not the new TTL you just set. If your A record had a TTL of 86400 (24 hours) and you change the IP, some resolvers will serve the old IP for up to 24 more hours. Lowering the TTL beforehand lets you control the maximum wait. Once the old TTL expires everywhere, the new record appears.

            Should I use a low TTL permanently for faster updates?

            No. Keeping TTL at 60 or 300 seconds permanently increases DNS query volume, raises hosting costs, and adds latency for every visitor lookup. Lower TTL to 300 before planned changes, then raise it back to 3600 or 86400 after the change stabilizes. The exception is active-active failover systems that need sub-5-minute switchover, which justify a permanent low TTL.

            Related articles