DNS Propagation: TTL, Caches, and Resolver Failures

DNS propagation is the delay between when you change a domain’s DNS records and when those changes are visible to all internet users worldwide. This delay is caused by TTL (Time to Live) values on DNS records, caching at multiple levels (browsers, operating systems, routers, and ISP resolvers), and occasional resolver failures or misconfigurations. In short, DNS propagation is not a single event but a gradual process that depends on how long each cache holds onto old data.

What Is DNS and Why Do Changes Take Time?

The Domain Name System (DNS) is the internet’s phonebook. It translates human-readable domain names like example.com into IP addresses like 93.184.216.34. When you update a DNS record—for example, changing your website’s IP address to point to a new hosting provider—you’re telling the authoritative nameserver (the DNS server that has the “official” records for your domain) to serve new information. However, most DNS queries never reach the authoritative server directly. Instead, they’re answered from caches—temporary storage locations that keep previously queried DNS results to speed up future requests. These caches exist at every level: your browser, your operating system, your router, and your ISP’s recursive resolver. Each cache has its own TTL, which dictates how long it will keep a record before discarding it and asking upstream for a fresh copy. Until every cache expires, some users will see the old IP address while others see the new one—this is what we call “propagation.”

How TTL Works and Why It Matters

TTL is a numeric value (in seconds) attached to every DNS record. It tells caching resolvers how long they can store that record before they must query the authoritative server again. For example, a TTL of 3600 means the record is valid for one hour. When you change a record, the old TTL still applies to the old value until it expires. So if you set a TTL of 86400 (24 hours) before making a change, some caches may keep the old IP for a full day. To minimize propagation time, you should lower the TTL to something like 300 (5 minutes) at least 24–48 hours before the change. After the change, you can raise it back to a higher value for performance. TTL values are not retroactive—they only affect how long the *new* record is cached, not the old one. This is a common misconception: lowering the TTL after the change does not speed up propagation.

The Caching Layers: Browser, OS, Router, and ISP

DNS responses are cached at multiple points, each adding potential delay. Understanding these layers helps you diagnose where a stale record might be coming from.

Browser cache: Chrome, Firefox, and others cache DNS results for a short time (usually 60 seconds to a few minutes). This is the easiest to clear—just restart the browser or use a private window.
Operating system cache: Windows, macOS, and Linux each have a DNS resolver cache. You can flush it with commands like ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache (macOS).
Router cache: Many home routers act as DNS forwarders and cache results. Rebooting the router clears this.
ISP recursive resolver: This is the most significant layer. Your ISP’s DNS server caches records according to the TTL. You can’t flush it directly, but you can bypass it temporarily by using a public DNS like Google (8.8.8.8) or Cloudflare (1.1.1.1).

Each layer must expire its TTL before it fetches the new record. If a resolver fails to query upstream (for example, due to a network issue), it may continue serving stale data even after the TTL expires—this is a resolver failure.

What Causes Resolver Failures and How They Delay Changes

Resolver failures are situations where a recursive DNS server cannot get a valid answer from the authoritative server. This can happen for several reasons:

Authoritative server downtime: If your DNS hosting provider is unreachable, resolvers can’t fetch the new record. They may return a SERVFAIL error or, worse, keep serving the last known good record from cache.
Network issues: Packet loss or high latency between the resolver and authoritative server can cause timeouts, leading to delayed updates.
Misconfigured glue records: If your domain’s nameservers are not properly set up (e.g., missing glue at the registrar), some resolvers may fail to find the authoritative server at all.
Negative caching: If a resolver receives a NXDOMAIN (domain doesn’t exist) response, it caches that negative result for a period (often 30–60 minutes). If you add a new subdomain, some resolvers may still say it doesn’t exist until the negative cache expires.

When a resolver fails, the delay can extend beyond the TTL. For example, if the TTL is 300 seconds but the resolver can’t reach the authoritative server for 10 minutes, the old record stays cached until the resolver successfully refreshes. This is why propagation can sometimes take longer than the TTL suggests.

How to Check Propagation and Verify Changes

You can’t “force” propagation, but you can monitor it. Several online tools query DNS servers around the world and show you which ones have the new record. Alternatively, use the command line:

Check your local cache: Use nslookup example.com or dig example.com to see what your system’s resolver returns.
Query a specific resolver: dig @8.8.8.8 example.com bypasses your local cache and asks Google’s DNS directly.
Query the authoritative server: dig @ns1.yourhost.com example.com shows the true current record, regardless of caches.
Use online checkers: Sites like whatsmydns.net query multiple global resolvers and display which ones have updated.

If your local resolver shows old data but the authoritative server shows new data, the issue is just cache—wait for TTL to expire or flush your local cache.

Common Misconceptions and Practical Tips

One common misconception is that DNS propagation is a single, global event. In reality, it’s a gradual rollout—some users see the new IP minutes after the change, while others may wait hours or days. Another misconception is that you can “speed up” propagation by setting a very low TTL at the time of change. As mentioned, the old TTL governs the old record, so this doesn’t help. Instead, plan ahead: lower TTL 24–48 hours before the change, make the change, then raise TTL back after a day or two. Also, be aware that some ISPs ignore TTLs and cache DNS records for longer periods (sometimes up to 48 hours) to reduce load. This is rare but can cause unusually long propagation. If you’re in a hurry, you can use a CDN or a reverse proxy that keeps a stable IP address, so you never need to change DNS records when moving servers.

Frequently Asked Questions

How long does DNS propagation take?

Typically, propagation takes anywhere from a few minutes to 48 hours. With a low TTL (e.g., 300 seconds), most caches update within 5–15 minutes, but some ISP resolvers may hold onto old records longer. The maximum delay is usually 24–48 hours, but in rare cases it can be longer.

Can I force DNS propagation to happen faster?

No, you cannot force it globally. You can only reduce the TTL before the change and flush your own local caches. You cannot control how long other ISPs or resolvers cache the old record.

Why does my website still show the old IP after 24 hours?

This could be due to a resolver failure, an ISP that ignores TTL, or a misconfigured authoritative server. Check the authoritative server directly with dig @your-nameserver to confirm the new record is live. If it is, the issue is on the resolver side—try flushing your local cache or using a different DNS server.

What is negative caching and how does it affect propagation?

Negative caching stores the fact that a domain or record doesn’t exist. If you add a new subdomain, some resolvers may have cached a previous NXDOMAIN response and will keep saying it doesn’t exist until the negative TTL expires (often 30–60 minutes). This is separate from positive caching.

Should I use a low TTL permanently?

Low TTLs (like 300 seconds) mean more queries to your authoritative server, which can increase load and response time. For most websites, a TTL of 3600 (1 hour) or 86400 (24 hours) is fine. Lower TTLs are only beneficial if you expect to make frequent changes or need fast failover.

Does changing my nameserver affect propagation differently than changing a record?

Yes. Changing nameservers (NS records) can take longer because registries (like Verisign for .com) update their own TTLs, which are often 48 hours. The old nameserver may also continue to serve DNS for a while. Record changes within the same nameserver propagate faster because only the authoritative server’s data changes.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →