DNS Propagation: What It Is and How Long It Takes

DNS Propagation

When you update a DNS record, the change does not instantly reach every device in the world. DNS propagation is the time it takes for that update to spread across all the DNS servers globally, and it can take anywhere from a few minutes to 48 hours depending on how your records were configured before the change.

What Is DNS Propagation

The internet does not have one central DNS server. There are thousands of recursive resolvers operated by ISPs, businesses, and public DNS providers worldwide. Each one caches DNS records based on the record's TTL value. When you change a DNS record at your registrar or DNS provider, the authoritative server reflects that change immediately. However, every resolver around the world that has already cached the old record will continue serving it until that cached copy expires.

Propagation is not a single event that starts and ends at a defined moment. It is a gradual process where different resolvers refresh at different times depending on when they last queried the record and what TTL value they are holding. A user whose ISP resolver refreshed its cache an hour before your change may see the old record for nearly a full TTL cycle. A user whose resolver cache just expired may get the new record within seconds of your change going live.

Why Propagation Takes Time

The delay is caused entirely by caching. Every resolver that cached your old record is permitted, by design, to keep serving that cached value until the TTL expires. If your DNS records had a TTL of 86400 seconds before you made a change, a resolver that refreshed its cache just before your update could continue serving the old record for up to another 24 hours.

This is why the TTL value you have set before making a change matters far more than any action you can take after the change. Lowering your TTL in advance is the single most effective way to reduce propagation time.

The Propagation Process Step by Step

Understanding the sequence of events during a DNS change helps set realistic expectations for how long propagation will take and why different users see different results at the same time.

1. You update a DNS record at your registrar or DNS hosting provider
2. The authoritative name server for your domain immediately reflects the new record
3. Recursive resolvers around the world still hold the old record in their cache and continue serving it to their users
4. As each resolver's cached copy reaches its TTL expiry, it discards the old record and sends a fresh query to the authoritative server
5. The authoritative server responds with the new record, and the resolver caches the updated value
6. Users behind that resolver now receive the new record for all subsequent lookups
7. Once every resolver's cache has expired and refreshed, propagation is complete globally

How to Speed Up DNS Propagation

You cannot force remote resolvers to flush their caches or fetch your updated record ahead of schedule. What you can control is how quickly those caches expire, and you can do this by planning your TTL reduction in advance.

• Lower your TTL before the change: Reduce the TTL on the records you plan to change to 300 seconds or less at least 24 to 48 hours before your planned migration. This gives the shorter TTL time to propagate to all resolvers. Once the short TTL is in place everywhere, your actual DNS change will propagate in minutes rather than hours.
• Flush your local DNS cache: You can clear your own device's cache immediately after making a change to verify the new record on your own machine. On Windows, run ipconfig /flushdns. On macOS, run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. This only affects your device and does not influence remote resolvers.
• Switch to a public DNS resolver temporarily: Resolvers like Cloudflare's 1.1.1.1 or Google's 8.8.8.8 often refresh cached records more quickly and more consistently than ISP resolvers. Changing your DNS server to a public resolver during a migration can give you faster access to the new record.
• Test from multiple locations: Use online propagation checking tools to see what different resolvers around the world are currently returning for your domain. This tells you how far propagation has progressed and whether specific regions are lagging.

How to Check Propagation Status

During a migration, different users may see different versions of your site or service depending on whether their resolver has the old or new record. Several tools let you query resolvers in different regions to monitor how propagation is progressing in real time.

• whatsmydns.net: Shows the current value of A, CNAME, MX, TXT, and other record types as seen from resolvers in locations around the world. Useful for a quick visual check of propagation status.
• dnschecker.org: Checks specific record types across over 100 worldwide locations and displays which regions have the new record and which still have the old one.
• nslookup (command line): Run nslookup yourdomain.com 8.8.8.8 to check your domain against Google's resolver specifically. Replace 8.8.8.8 with 1.1.1.1 to check against Cloudflare. The response shows which record that resolver is currently serving.
• dig (command line): Run dig yourdomain.com @8.8.8.8 for more detailed output including the TTL remaining on the cached record, which tells you how much longer that resolver will hold the current value before refreshing.

Nameserver Changes vs Record Changes

Not all DNS changes propagate at the same speed. Changing an individual DNS record such as an A record or CNAME is governed by the TTL you set on that record. Changing your nameservers is a different and typically slower process.

Nameserver records are maintained at the domain registry level, not at your DNS provider. The registry, which is the organisation that manages the top-level domain such as .com or .org, controls the NS records and sets its own TTL, often between 24 and 48 hours regardless of any TTL you specify. This means a nameserver migration takes longer than a record-level change and is less predictable in timing. During the transition period, some queries will be answered by the old nameservers and some by the new ones, so both sets of nameservers must serve consistent records until propagation is complete.

Frequently Asked Questions

1. My DNS change shows up for me but not for my colleague. Why?
   Your ISP's recursive resolver has already expired its cached copy of the old record and fetched the new one, while your colleague's resolver has not. This is completely normal during propagation and is not a sign that something went wrong. It resolves on its own as each resolver's TTL expires. Your colleague can try flushing their local DNS cache or temporarily switching to a public resolver like 1.1.1.1 to access the new record sooner.
2. Does changing nameservers take longer to propagate than changing individual records?
   Yes, typically significantly longer. Nameserver records are managed by the domain registry and carry TTLs set by the registry itself, often 24 to 48 hours, which you cannot override. A records and CNAME records managed at your DNS provider propagate according to the TTL you set, which can be as short as 60 seconds. For this reason, nameserver migrations require more lead time and planning than simple record changes.
3. Does DNS propagation affect email delivery?
   Yes. MX records, which control where email for your domain is delivered, propagate the same way as all other DNS records. During the propagation window after an MX change, some sending mail servers may still resolve the old record and deliver to your previous mail server. Lowering the TTL on your MX records well before an email migration and keeping the old mail server active until propagation is complete helps prevent messages from being lost or delayed during the transition.
4. Can I check what TTL a resolver currently has cached for my record?
   Yes. The dig command-line tool shows the TTL remaining on a cached record in its response output. Run dig yourdomain.com @8.8.8.8 and look at the number in the answer section next to your record. That number is the seconds remaining until that resolver's cache expires and it fetches a fresh copy. Running the same command a minute later will show a lower number if the resolver is counting down the existing cache rather than serving a freshly fetched record.
5. What happens to visitors during DNS propagation?
   Visitors are routed based on whichever record their resolver currently has cached. If their resolver has the old record, they reach your old server. If it has the new record, they reach your new server. During a server migration this means you need to keep both the old and new servers operational and serving the same content throughout the propagation window. Taking the old server offline before propagation is complete will cause errors for users whose resolvers still point to it.

Conclusion

DNS propagation is not a problem to fix but a designed behaviour of the distributed DNS system. Because thousands of independent resolvers cache records according to their own TTL expiry schedules, changes spread gradually rather than instantly. The most reliable way to manage propagation is to lower your TTL days before a planned change, verify the new record is live using propagation checking tools, and keep old infrastructure running until the transition window closes. See also DNS caching, DNS records, and how DNS works for a complete understanding of the domain name system.