DNS Propagation Explained for New Users

What DNS Propagation Actually Is

If you have ever changed a DNS record and heard someone say "wait for propagation," you have encountered one of the most misunderstood concepts in web hosting. The word "propagation" suggests something actively spreading across the internet like a wave, but that is not what happens at all. DNS propagation is not a push mechanism. There is no central switch that flips and instantly updates every DNS resolver on the planet.

The reality is far simpler: every DNS resolver caches the answers it receives for a specified duration called the Time To Live (TTL). When you change a record at your DNS provider's authoritative layer, you are updating the source of truth. But every resolver that already looked up the old value will keep using it until its cached copy expires. "Propagation" is just the gradual process of those cached entries expiring and being refreshed with the new value.

How DNS Caching Works at Every Level

DNS caching happens at multiple independent layers, and each layer has its own cache with its own TTL policy. Understanding these layers explains why propagation appears uneven.

Browser-Level Caching

Modern browsers maintain their own internal DNS caches. Chrome typically caches DNS for 60 seconds by default, though this can vary. You can inspect Chrome's DNS cache by navigating to chrome://net-internals/#dns. Firefox stores its cache in about:networking#dns. Browser caching is often the first place stale data gets stuck because users rarely think to clear it.

Operating System-Level Caching

Your operating system runs a stub resolver that caches DNS queries system-wide. On Windows, this is the DNS Client service (svchost.exe). On macOS, mDNSResponder handles it. On Linux, it is typically systemd-resolved or dnsmasq. This cache strictly respects TTL values and will not re-query the upstream resolver until the TTL expires. Even if the authoritative record changed seconds ago, your OS will faithfully serve the old cached answer.

Router-Level Caching

Many home and office routers run a DNS proxy or forwarding service that caches queries for all devices on the network. A router with DNS caching can serve stale records to every device on your LAN, making it look like the entire network has not propagated. Rebooting the router often clears this cache.

ISP-Level Caching

Your Internet Service Provider runs recursive resolvers that serve all their customers. ISPs are often aggressive about caching because sharing cached answers reduces their upstream bandwidth costs and improves perceived performance. Some ISPs ignore short TTLs or enforce a minimum cache time of 30 to 60 minutes. This is why a record change can appear instantaneous on one ISP but take hours on another—they each set their own caching policies.

Public Resolver Caching

Services like Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), and OpenDNS (208.67.222.222) each maintain independent caches. Google Public DNS respects TTL but enforces a minimum of 30 seconds for stability. Cloudflare's 1.1.1.1 is known for honoring TTLs strictly. You can query a specific resolver to see what value it currently serves:

dig @1.1.1.1 yourname.is-pro.dev A +short
dig @8.8.8.8 yourname.is-pro.dev A +short

Application-Level Caching

Some applications and frameworks maintain their own DNS caches. Java applications have a built-in DNS cache managed by the JVM. Python's requests library uses the OS resolver by default, but libraries like aiohttp or httpx may cache DNS independently. Nginx and HAProxy can cache DNS lookups for upstream servers, which causes surprising delays when backend IPs change.

TTL Explained: Time To Live

TTL is the single most important DNS concept that most people overlook. Every DNS record includes a TTL value expressed in seconds. This value tells recursive resolvers how long they are allowed to cache the answer before they must query authoritative DNS again. TTL is set by the domain owner at the DNS provider level.

How TTL Works in Practice

When a resolver queries yourname.is-pro.dev and receives an answer with TTL 3600, it stores that answer and starts a countdown timer. For the next 3600 seconds (1 hour), it will return the cached answer to any client without re-querying. Only after the timer reaches zero will it perform a fresh query to authoritative DNS.

Choosing the Right TTL

TTL is a tradeoff between performance and flexibility. There is no single "correct" value—it depends on your use case:

• TTL 300 (5 minutes): Best for environments where records change frequently. Use this during migrations, CDN setup, or A/B testing. The downside is increased query volume to your DNS provider's authoritative infrastructure, which can matter at scale or on metered DNS plans.
• TTL 3600 (1 hour): A solid default for stable production records. It offers a reasonable balance: changes propagate within an hour, but cache hit rates remain high enough to reduce resolver load.
• TTL 86400 (24 hours): Appropriate for records that almost never change, like MX records, static SPF includes, or DKIM public keys. Reduces DNS query volume significantly, but any change takes a full day to propagate everywhere.
• TTL 604800 (7 days): Rarely used today. Only suitable for extremely stable records like NS glue records. Changing a 7-day TTL record means waiting a week for full propagation.

Why Propagation Seems Slow: Common Misconceptions

The most pervasive misconception is that DNS changes propagate like a radio broadcast—that a signal goes out and every resolver receives it simultaneously. DNS does not work this way at all. A resolver will not even know a change exists until its cached TTL expires and it performs a fresh query. It has no mechanism to receive push notifications.

Here are the most common misconceptions, debunked:

"I changed the record, why is my site still showing the old version?" Your browser almost certainly has the old IP cached. Before blaming DNS, try a hard refresh (Ctrl+F5 or Cmd+Shift+R) or clear the browser cache. Chrome's DNS cache lives at chrome://net-internals/#dns.

"I lowered the TTL but the change is still slow." TTL only affects future caching decisions. Any record that was already cached before you lowered the TTL will still use the original TTL for expiration. You cannot retroactively shorten the lifetime of an already-cached record. This is why you lower TTL before making the change.

"My registrar says propagation takes 24-48 hours." This is a CYA number. It dates from the early days of DNS when caching was far more aggressive and TTLs were routinely set to days. In practice, with reasonable TTLs, most resolvers pick up changes within minutes to an hour. The 48-hour figure is the worst-case scenario that covers every possible caching edge case.

"I see the old IP from my phone but the new one from my laptop." Your phone uses the mobile network's DNS resolver while your laptop uses your home ISP's resolver. Each resolver has its own independent cache. They will expire at different times. This is normal and expected behavior.

"I flushed my DNS cache and it still does not work." Flushing your local OS cache only affects your machine. It does not flush your ISP's resolver, Google Public DNS, or Cloudflare's resolver. You cannot remotely flush other people's caches.

Real Example: Watching Propagation in Action

Let us walk through a concrete scenario. You manage app.yourname.is-pro.dev and want to move it from Netlify to Vercel. You change the CNAME from your-site.netlify.app to your-site.vercel.app and set the TTL to 300 seconds.

Immediately after saving, check an authoritative nameserver. Find one first, then query it directly. It should return the new value because the change was made there:

dig NS is-pro.dev +short
dig @<authoritative-ns> app.yourname.is-pro.dev CNAME +short
your-site.vercel.app.

Now query Google Public DNS. If Google has cached the old value recently, it will still return the old target:

dig @8.8.8.8 app.yourname.is-pro.dev CNAME +short
your-site.netlify.app.

Wait 300 seconds (5 minutes) for the old cache to expire, then query again:

dig @8.8.8.8 app.yourname.is-pro.dev CNAME +short
your-site.vercel.app.

Now Cloudflare's resolver:

dig @1.1.1.1 app.yourname.is-pro.dev CNAME +short
your-site.vercel.app.

Each resolver will transition from old to new independently as its TTL expires. Some resolvers (like your ISP's) may cache more aggressively and take longer. This staggered expiration across potentially millions of resolvers is what people call "propagation."

How to Check Propagation Status

Using dig (Linux/macOS)

The dig command is the most powerful DNS debugging tool available. Query specific nameservers to compare answers:

# Find authoritative nameservers for the zone
dig NS is-pro.dev +short

# Query an authoritative nameserver directly
dig @<authoritative-ns> yourname.is-pro.dev A +short

# Query a public resolver
dig @8.8.8.8 yourname.is-pro.dev A +short

# Query another public resolver for comparison
dig @1.1.1.1 yourname.is-pro.dev A +short

If the authoritative answer matches the resolver answer, propagation is complete for that resolver. If they differ, the resolver is still serving cached data.

To see the TTL remaining on a cached record, omit +short:

dig @8.8.8.8 yourname.is-pro.dev A

; <<>> DiG 9.10.6 <<>> @8.8.8.8 yourname.is-pro.dev A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
yourname.is-pro.dev. 237 IN A 203.0.113.10

The number 237 is the remaining TTL in seconds. When this reaches 0, the resolver will re-query.

Using nslookup (Windows/macOS/Linux)

Windows does not ship with dig by default, but nslookup is available on all platforms:

# Query the default resolver
nslookup yourname.is-pro.dev

# Query a specific resolver
nslookup yourname.is-pro.dev 8.8.8.8

Using Online Tools

Websites like whatsmydns.net and dnschecker.org query DNS resolvers from multiple geographic locations simultaneously. These are useful for a quick visual check, especially when troubleshooting with less technical stakeholders who want to see a world map of green checkmarks.

For more advanced diagnostics, dns.google and Cloudflare's resolver checker provide detailed information about how your DNS is being resolved.

How to Flush DNS Cache on Every Platform

When you need to force your local system to re-query, flush the cache at the appropriate level.

Windows

ipconfig /flushdns

Open Command Prompt as Administrator and run this. The DNS Client service will discard all cached entries. You should see "Successfully flushed the DNS Resolver Cache."

macOS

For macOS Ventura and later (Apple Silicon and Intel):

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux

For systems using systemd-resolved (Ubuntu, Fedora, Debian with systemd):

sudo resolvectl flush-caches

For systems using dnsmasq:

sudo systemctl restart dnsmasq

For systems using nscd (older Red Hat/CentOS):

sudo systemctl restart nscd

Browser Cache

• Chrome/Edge: Navigate to chrome://net-internals/#dns and click "Clear host cache."
• Firefox: Navigate to about:networking#dns and click "Clear DNS Cache."
• Safari: Restart Safari completely, or use the macOS flush command above since Safari relies on the system resolver.

Best Practices for Minimizing Propagation Issues

• Plan ahead with TTL reduction: Reduce TTL to 300 seconds at least 48 hours before a planned change. This ensures old cached records expire quickly when you make the actual update. After the change is verified, you can raise the TTL back to a higher value.
• Stage changes on subdomains first: If possible, test your setup on a non-production subdomain before changing production records. Point staging.yourname.is-pro.dev to the new provider and validate everything works before touching www.yourname.is-pro.dev.
• Always verify authoritative first: Before assuming propagation is the issue, confirm the record is correct at the authoritative DNS level. If the authoritative answer is wrong, no amount of waiting will fix it.
• Document your DNS configuration: Maintain a record of all DNS entries, their TTLs, and their purpose. Tools like DNSControl or a simple spreadsheet help track what you have and prevent accidental conflicts.
• Monitor DNS health: Services like DNS Spy, DNSPerf, or Checkly can alert you when DNS records change unexpectedly or when resolvers return inconsistent answers.
• Use a TTL calculator: Before a migration, calculate the worst-case propagation time. If your MX record has TTL 86400 and you lower it to 300 now, it takes up to 24 hours for the lower TTL to be picked up by resolvers that already cached the old TTL.

Common Errors and Fixes

"I changed the record but nothing happens"

Check authoritative DNS first: dig NS is-pro.dev +short then dig @<authoritative-ns> yourname.is-pro.dev A. If the authoritative answer is wrong, the change was not saved properly at the DNS provider. If it is correct, check browser cache and OS cache before blaming propagation. If all local caches are clean and you still see the old value, you are waiting for your ISP's resolver or a public resolver to expire its cache.

"Some users see the old site, others see the new one"

This is normal during propagation. Each resolver expires its cache independently. Users on ISP A may see the new site while users on ISP B see the old one for another hour. The solution is patience, or better TTL management before the change.

"Emails are bouncing after a DNS change"

MX records traditionally have long TTLs (86400 seconds or more). If you changed email providers, the old MX record may still be cached. Sending servers will attempt delivery to the old mail server, which no longer accepts mail for your domain. Always reduce MX TTL well before migrating email, and keep the old mail server running for at least 48 hours during the transition.

"dig shows the correct record but the website still fails"

If DNS is correct but the website does not load, the issue is not propagation. Check whether the new server is configured to accept requests for your domain name. Check whether SSL/TLS certificates are valid for the domain. Check whether the web server process is actually running. DNS propagation is often blamed for problems that are actually server configuration issues.

"Google Search Console says domain not verified"

Google's verification check queries the DNS and expects an exact match. Make sure the TXT record value is copied precisely with no extra spaces or quotes. Check that the record is on the correct subdomain (e.g., _googleconsole.yourname.is-pro.dev). Use dig yourname.is-pro.dev TXT to verify the record is published correctly before clicking "Verify" in Search Console.

Common mistakes

• Confusing local browser cache behavior with global resolver propagation.
• Lowering TTL immediately before change and expecting instant effect.
• Skipping authoritative resolver checks before troubleshooting clients.

How to verify it works

1. Compare authoritative DNS vs public resolver answers over time.
2. Measure remaining TTL from resolver responses during transition.
3. Validate final endpoint behavior after resolver values converge.