DNS Time to Live – What It Is and Why It Matters When Moving a WordPress Site

When I recently moved a WordPress website to a new host, I updated the DNS A record to point to the new server. Everything on the backend was ready, but the live site didn’t switch over immediately. Why? Because the DNS Time to Live (TTL) was set to 86400 seconds—that’s a full 24 hours. If you’ve ever wondered how long DNS changes take to update, TTL is the reason.

Let me break down what DNS TTL means and share some best practices, especially if you’re about to migrate a website.

---

What Is DNS TTL (Time to Live)?

In simple terms, DNS TTL tells other servers how long they should cache the DNS information (like your domain’s A record) before asking again for updated info. It’s measured in seconds.

Here are some common TTL values:

• 3600 = 1 hour (a typical default)
• 300 = 5 minutes (great for temporary changes)
• 86400 = 24 hours (often used for stability)

Each DNS record (A, CNAME, MX, etc.) can have its own TTL. If your TTL is long, DNS changes can feel sluggish. If it’s short, changes happen faster—but your authoritative DNS server gets queried more often.

What Does a DNS Server Do—and Why Is DNS Cached?

When someone visits your website, their browser needs to convert your domain (like example.com) into an IP address. That’s the job of a DNS server—it resolves human-readable domain names into server IPs.

To avoid asking that same question over and over, DNS servers cache the result for a set amount of time—that’s where TTL comes in. It tells the DNS server how long to store the result before checking back for changes.

That’s why when you update a DNS record, the change doesn’t take effect instantly everywhere. Some servers are still using the old, cached data until the TTL expires.

Want to go deeper? Here’s how I built my own DNS server on a Synology NAS.

---

How Long Do DNS records Change Take to Update?

A common question is: how long does it take for DNS records to update?

There’s no one-size-fits-all answer. It depends entirely on the previous TTL setting. For example:

• If your A record had a TTL of 86400 seconds (like mine), DNS resolvers may keep using the old IP for up to 24 hours.
• If you had set it to 300 seconds, the update could take just 5 minutes to propagate.

This also applies to CNAME records and nameserver changes. Tools like whatsmydns.net let you track real-time DNS propagation worldwide.

In practice, I’ve noticed that large DNS providers like Google DNS (8.8.8.8) and Cloudflare (1.1.1.1) often refresh their cache more frequently than the TTL suggests. For example, I was able to request a new SSL certificate shortly after the A record change—even though the TTL was set to 86400.

That said, not all resolvers behave this way. Some DNS servers around the world strictly follow the TTL and won’t refresh until the full time has passed. That’s why it’s still important to lower TTL ahead of time if you need guaranteed speed.

---

DNS Time to Live Best Practices

Here’s what I recommend when dealing with DNS changes:

• Lower the TTL to 300–600 seconds at least 24 hours before making your move. This gives DNS resolvers a shorter cache window.
• Make your DNS change (e.g., update A record to new host).
• Wait for propagation, using DNS lookup tools to verify.
• After propagation, increase the TTL back to 3600 or even 86400 for better long-term performance and fewer DNS queries.

Avoid leaving it permanently low—short TTLs increase load on your DNS infrastructure.

Tip: A higher TTL reduces DNS traffic and server load, which is ideal for stable, unchanging records. But keep in mind—it also introduces latency when you need to make updates, since resolvers hold onto the cached data longer.

One more thing: Some internet service providers (ISPs) and corporate networks may ignore your TTL settings and use their own refresh intervals. So even if you’ve set a short TTL like 300 seconds, certain resolvers might still hold onto the old data longer than expected. That’s why it’s smart to plan a buffer period after the change—just in case.

Interestingly, the majority of DNS records on the Internet are configured with TTLs of 5 minutes or less. While this allows for fast changes, it often undermines effective caching, leading to more frequent DNS lookups and unnecessary load on authoritative servers. Unless your records change often, longer TTLs are typically more efficient.

---

Minimum TTL Values – How Low Can You Go?

Some DNS providers allow very low TTLs, like 60 seconds or less. But unless you’re running a service that requires rapid failover or global routing changes, there’s rarely a need to go that low.

I usually stick to:

• 300 for planned changes
• 3600 for normal operation
• 86400 for rarely changed records (like MX or SPF)

The maximum DNS TTL value is typically set to 86400 seconds (24 hours) for most users.

---

How to Change TTL in Cloudflare (And Why Auto Might Mislead You)

If you’re using Cloudflare as your DNS provider, TTL behavior works a bit differently depending on whether your record is proxied through Cloudflare’s CDN or not.

• If the record is proxied (orange cloud), the TTL is automatically set to 5 minutes, and you can’t manually change it—it’s always listed as “Auto.”
• If the record is set to DNS only (gray cloud), you can manually select the TTL from 1 minute to 1 day.

Here’s how that looks in the Cloudflare dashboard:

Note: This behavior is specific to Cloudflare. Other DNS providers let you set the TTL freely regardless of proxying.

Don’t Forget Your Local DNS Cache

Even after a DNS record has been updated and propagated globally, your local system may still cache the old DNS entry. This includes:

• Your browser (e.g., Chrome, Firefox)
• Your operating system’s DNS cache
• Your router or internal network’s DNS resolver

If you’ve made a DNS change but still see the old site or IP:

• Try a different device or network
• Use a tool like nslookup or dig from the terminal
• Clear your local DNS cache:
• On Windows: ipconfig /flushdns
• On macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• On Linux: Restart systemd-resolved or nscd if used
• On Windows: ipconfig /flushdns
• On macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• On Linux: Restart systemd-resolved or nscd if used

This is why even with a low TTL, some users still experience delays—their local cache simply hasn’t been cleared yet.

If you’re curious to dive deeper into your domain’s DNS setup, you can analyze your DNS configuration in detail with DNSViz. It provides a visual breakdown of your records, validation, and any potential issues—especially useful if you want to debug propagation or DNSSEC problems.

Conclusion

DNS time to live isn’t something most WordPress users think about—until a migration or DNS change takes longer than expected. Understanding how TTL affects DNS propagation helps you plan ahead and avoid unnecessary delays.

If you’re preparing to move a site or change records, always check your TTL setting. Lower it first, wait for the short TTL to kick in, then make your change. And once everything is live? Don’t forget to raise it again.

I’d love to hear from you. Was this article helpful? Share your thoughts in the comments below. If you prefer, you can also reach me by email or connect with me on Reddit at Navigatetech.

---

FAQ