DNS Propagation Explained: Why Changes Aren't Instant

Before we talk about "propagation" — a word that, frankly, is a little misleading — you need a clear mental picture of what DNS actually is and, more importantly, how DNS caching works. The whole reason DNS changes feel slow is sitting inside that one word: caching.

DNS is the internet's address book. Computers do not know what `example.com` is. They only know how to talk to numeric addresses like `203.0.113.10` (or the longer IPv6 form). Every time you type a website name into your browser, click a link in an email, or open an app on your phone, your device has to translate that human-friendly name into a numeric address before any traffic can flow. The translation system is called DNS (Domain Name System), and it has been quietly doing this job since 1983. It is one of the most-used pieces of infrastructure on the planet.

Now here is the part that matters for understanding "propagation": DNS would be unbearably slow if every lookup actually went all the way to the source every time. Imagine if every Google search you did had to start from scratch — no autocomplete, no history, no shortcut. That is what un-cached DNS would feel like. To make DNS feel instant, the entire system is built around caching: every server, every router, every operating system, every browser keeps a temporary copy of every answer it has recently looked up. The next time someone asks the same question, the cached copy is handed back immediately. The actual authoritative source — the one that holds the real answer — is only consulted when no cached copy exists.

Caching is what makes DNS fast. It is also the reason "propagation" exists. When you change a DNS record, your authoritative nameserver knows the new answer immediately. But every cached copy of the old answer, sitting in routers and resolvers around the world, will keep handing out the old answer until that cache expires. "Propagation" is not a file transfer or a synchronization process. It is just the slow expiration of every cached copy of the old value. Once every cache has expired and refreshed, the new answer is universal.

How long does that take? It depends on a single number called the TTL (time to live), which is attached to every DNS record. The TTL says, in seconds, how long a cached copy is allowed to live before it must be refreshed. A TTL of 300 means caches must refresh every 5 minutes; a TTL of 86400 means once every 24 hours. The TTL is the single most important lever you have over how fast or slow your changes spread. The rest of this guide is going to keep coming back to that one word.

One final misconception to clear up: there is no "DNS network" passing your update around. Each cache simply notices its copy is too old and goes back to the source for a fresh one. There is no broadcast. There is no orchestration. There is just a planet full of independent caches, each running its own little timer. Once you understand that, the rest of this guide will read like a series of practical tips for working with the caching, instead of against it.

DNS (Domain Name System) is the internet's address book. Computers don't actually know what `example.com` is — they only know how to talk to numeric addresses like `203.0.113.10`. So when you type a website name into your browser, your computer first asks DNS, "hey, what's the actual address for this name?" DNS hands back the number, and your browser uses it to connect to the right server.

This happens billions of times a second across the internet. Because looking up the same answer over and over would be slow and wasteful, every step of the lookup process keeps a temporary cached copy. That caching is the whole reason "propagation" exists.

Here's the journey, in order, when you type `example.com` into your browser for the first time:

1. Your device checks its own little memory. "Have I looked this up recently?" If yes, done. 2. Your operating system checks its own memory. Same question. 3. Your DNS resolver (your home router, your office network, or a public service like Google's `8.8.8.8`) checks its memory. 4. If the resolver hasn't seen this name before, it asks the root nameservers: "who's in charge of `.com`?" 5. The root sends it to the TLD (top-level domain) nameservers for `.com`, which say: "the answers for example.com live at these nameservers over here." 6. The resolver asks those authoritative nameservers for the actual address. 7. The authoritative nameserver answers: "203.0.113.10." 8. Every step in this chain caches the answer for some amount of time so it doesn't have to do all that work again.

That last step is the key. Once the resolver has cached `example.com → 203.0.113.10`, it'll keep handing out that same answer to everyone who asks, until the cache expires.

Propagation is the time it takes for a DNS change you just made to spread out to every cached copy around the world.

Here's the catch: thousands of DNS resolvers (one at every internet provider, every office, every cloud region) have their own cached copies of your DNS records. When you update your record, your authoritative nameserver knows the new answer immediately. But all those caches around the world are still happily handing out the old answer to anyone who asks — until their cache expires.

A change is "fully propagated" once every cache has either: - noticed its cached copy is too old and fetched the new one, or - never had a cached copy in the first place and goes to your nameserver fresh.

In practice, propagation is never 100% complete in some perfect sense, because new caches keep appearing. The realistic measure is: have all the major public resolvers (Google, Cloudflare, OpenDNS, Quad9) refreshed yet? When the answer is yes, your change has effectively reached the whole world.

TTL (time to live) is the magic number that controls everything. It's a value, in seconds, attached to every DNS record. It tells caching resolvers, "you can remember this answer for this many seconds before you have to come ask me again."

Common TTL values you'll see in the wild: - 300 (5 minutes) — short. Use this when you're about to make a change. - 3600 (1 hour) — the most common default for records that change occasionally. - 86400 (24 hours) — common for records that almost never change. - 604800 (1 week) — the maximum most providers will let you set.

The math is simple: if your record has a TTL of 3600, it can take up to one hour for the entire internet to refresh after a change. Lower TTL means faster propagation, but also more lookups (which can mean very slightly more cost and slightly slower page loads on first visit).

The trick is to lower your TTL well before you actually make the change. If you set the TTL to 300 seconds 24 hours ahead of time, then by the time you actually change the record, no resolver in the world has a long-cached copy of the old value. Your change propagates in five minutes instead of an hour.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about DNS propagation? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

The first reason is operational: guessing wrong about propagation costs you downtime. If you change a DNS record and assume it has propagated when it has not, customers get the old IP address, the old mail server, the old certificate, the old everything. They see broken pages, bounced emails, security warnings, and "site can't be reached" errors. The classic version of this story is a website migration where the new server is online and tested but half the world is still being routed to the old (now empty) server because nobody waited for the cache to expire. The fix is always the same — wait — but the embarrassment is real and the lost revenue is real too.

**The second reason is strategic: knowing when to wait and when to act is one of the most undervalued skills in operations.** Experienced engineers do not panic when a DNS change "isn't working yet." They check the TTL (time to live) on the old record, do the simple math, and know exactly how long until the slowest cache will refresh. Less-experienced engineers try to "fix" propagation by making more changes, which only resets the clock and confuses the issue.

Picture this in real life. A solo developer is migrating his side-project from Heroku to Fly.io. He updates the A record at his registrar at 2 PM. By 2:15 PM the new site is loading correctly on his laptop, so he tweets that the migration is done. At 2:30 PM his biggest customer messages him saying the site is broken. He panics and starts rolling back the change, which only makes things worse. The actual problem is that his customer is on a corporate network whose DNS resolver had cached the old A record at the original 1-hour TTL, and there were still 45 minutes left on that cache. If he had simply lowered the TTL to 300 seconds the day before the migration, the cache would have flipped over within 5 minutes and the whole situation would never have happened.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, a propagation check is built for you:

• Did the DNS change I just made actually take effect everywhere in the world?

• Is the entire internet still serving the old answer, or just one network?

• How much longer should I wait before declaring the migration done?

You can either run the check yourself with the free EdgeDNS DNS propagation checker, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and explain the result conversationally.

Who gets the most out of this guide. Founders running their own infrastructure, marketers coordinating launches with hard go-times, IT admins inheriting domains from a former employee, and ops engineers troubleshooting live outages. If you have ever made a DNS change and wondered "is it live yet?", this guide is for you.

What happens if you skip this entirely. You're flying blind on the one piece of config that decides whether your website and email work at all. Skip it and you risk downtime during a launch, customers being routed to the old IP for hours after a cutover, broken email mid-migration, and the awful feeling of not knowing whether the right move is to wait or to roll back. That is why running this check before and after every DNS change is one of the cheapest forms of insurance you can give your operation.

If you're still on the fence about whether a propagation check belongs in your toolbox, this section is for you. Below you'll meet three real people facing three real situations where running a propagation check turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: The founder migrating to a new host

Imagine you're a solo founder running a SaaS product on a single VPS. You've outgrown the old host and you're moving to a new provider. The new server is set up, the database is migrated, the application is running, and you've tested the new IP address by editing your local hosts file. Everything works. Now comes the actual cutover: you change the A record at your registrar from the old IP to the new IP. You expect the change to be instant. It is not. For the next hour, half your test devices show the new server and half show the old one — and you have no idea which half your real customers are on. Running a propagation check across global resolvers tells you exactly how far the new IP has spread, so you know whether to send the launch email now or wait another twenty minutes. Your registrar will not give you this answer; only a global propagation checker will.

Why it matters: Migrations are stressful enough without the extra anxiety of not knowing whether your customers are seeing the new world or the old one. A propagation check turns a vague worry into a concrete percentage.

Story 2: The ops engineer in a maintenance window

Imagine you're an ops engineer at a 100-person SaaS company. You have a one-hour scheduled maintenance window starting at 2 AM Sunday to fail over your customer-facing API to a new region. The runbook calls for changing the DNS at minute 15 of the window, then declaring success at minute 45 if everything looks good. Without a global propagation check, all you can see is whether your monitoring system has picked up the new IP — but your monitoring lives in the same data center as the new region, so of course it shows the new IP first. Customers in Europe and Asia might still be hitting the old endpoint for another twenty minutes. With a propagation check across multiple global resolvers, you can confirm by minute 35 that 90+% of public resolvers have the new answer and then close the window with confidence.

Why it matters: Maintenance windows are measured in minutes. The wrong call between "declare success" and "roll back" can turn a 1-hour window into a 4-hour incident.

Story 3: The marketer waiting for a domain rename to flip live

Imagine you're a marketing manager whose company just rebranded. The old domain `oldname.com` is being retired and the new domain `newname.com` is going live tomorrow morning. The DNS team made the change at 9 PM the night before, but the press release is scheduled to send at 9 AM the next day, with hard deadlines from journalists. The CEO wants to know — at 8:45 AM, fifteen minutes before send time — whether the new site is actually loading worldwide or whether you should hold the press release. You don't have a DNS team member online. You open the free EdgeDNS propagation checker and type in `newname.com`. Within five seconds you have a global heat map showing every major resolver returning the new answer. You tell the CEO it's safe. The press release goes out on time.

Why it matters: Marketing launches are scheduled to the minute. Knowing — not guessing — whether DNS is live before you push the button is the difference between a clean launch and an embarrassing one.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for a propagation checker. If any of these are on your calendar this month, that's your sign:

• Right before launching a new website or migrating to a new host.

• After making any DNS change, to confirm the new settings are live everywhere.

• When customers report that your site or email "just stopped working" out of nowhere.

• As a recurring monthly health check to catch silent misconfigurations early.

Still not sure? Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Has the DNS change for example.com finished propagating?" The assistant will run the check across global resolvers and give you a straight answer in plain English.

The easiest way to check propagation is to ask several DNS resolvers around the world the same question and see if they all give the same answer. Three options, in order of friendliness:

Easiest: use the free EdgeDNS DNS propagation checker. It queries Google, Cloudflare, OpenDNS, Quad9, and other resolvers automatically and shows you who has the new answer and who's still serving the old one.

Easier (if you're using AI): if you have the EdgeDNS MCP server connected to Claude, ChatGPT, or Gemini, just ask: "Has the A record for api.example.com finished propagating to the new IP?" The AI will run the check across global resolvers and tell you when it's safe to proceed.

Nerdy: ask each resolver yourself from the command line:

You can't force the entire internet to refresh on demand, but you can do five things to make propagation as fast as possible:

1. Lower your TTL 24–48 hours in advance. This is the single biggest lever. Drop your TTL to 300 (5 minutes) at least a day before the planned change. By the time you actually make the change, every cache has a short-lived copy.

2. Flush your own machine's cache so you can see the change immediately yourself: - macOS: `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` - Windows: `ipconfig /flushdns` - Linux: `systemd-resolve --flush-caches`

3. Verify the change is live on your authoritative nameserver first. Before you start refreshing browsers, confirm the change actually saved correctly: `dig @ns1.your-dns-provider.com example.com A`. If your authoritative server doesn't have the new value yet, no amount of waiting will help.

4. Use DNS prefetch on your website. The HTML `<link rel="dns-prefetch">` tag tells browsers to start resolving a domain early, which can smooth over the transition.

5. Watch the propagation in real time. Use the DNS propagation checker and refresh every minute or so. You'll see resolvers update one by one. When they're all green, you're done.

Sometimes propagation drags on longer than expected. Here are the usual suspects, in order of how often they're the problem:

Stale resolver cache. Some Internet Service Providers override your TTL with their own minimum (often 5 minutes to an hour). So even if you set TTL=60, they'll cache for 300 seconds anyway. There's nothing you can do — just wait.

Negative caching. If anyone asked for your record before it existed, the resolver cached the absence of an answer. This negative cache is controlled by a separate setting (the `minimum` field on the SOA record) and can be up to 24 hours. Fix: lower the SOA minimum, or just wait it out.

Multiple authoritative servers out of sync. Most DNS providers run several nameservers. If the change reached the primary but hasn't replicated to the secondaries yet, some resolvers will see the new value and others the old one. Usually resolves within a minute or two.

Your CDN is in the way. Content Delivery Networks (CDNs) like Cloudflare and CloudFront often add their own DNS layer on top. Check your CDN dashboard for any DNS-level overrides.

Your browser is caching independently. Browsers have their own DNS cache, separate from your operating system. Try a different browser, an incognito window, or visit `chrome://net-internals/#dns` in Chrome to manually flush.

Your home router is caching. Many routers run a tiny DNS forwarder that caches results. Restarting the router clears this cache.

DNS (Domain Name System) — the internet's address book. Turns names into numbers.

A record — a type of DNS entry that maps a domain name to an IPv4 address.

Resolver — the DNS server that does the work of looking things up on your behalf. Your home router, your office network, and public services like 8.8.8.8 are all resolvers.

Authoritative nameserver — the DNS server that holds the real answer for your domain. When you change a DNS record at your provider, you're updating the authoritative nameserver.

TTL (time to live) — how long, in seconds, a cached DNS answer is valid before it has to be refreshed.

Caching — storing the answer to a question for a while so you don't have to ask again. The whole reason DNS feels fast — and the whole reason propagation isn't instant.

MCP (Model Context Protocol) — the standard that lets AI assistants call DNS tools directly so you can just ask them, "is this DNS change live yet?"