← Back to Blog

You just updated your website's DNS records. Maybe you moved to a new hosting provider, switched CDNs, or migrated your email to a new platform. You made the change, verified it in your DNS provider's dashboard, and waited. An hour later, you check from your phone and the old site still loads. You ask a colleague in another city to check, and they see the new site. Your boss checks from home and gets a timeout error.

Welcome to DNS propagation: the most misunderstood and most complained-about aspect of the Domain Name System.

DNS propagation is not actually a single process. It's the cumulative effect of thousands of independent caching resolvers around the world expiring their cached copies of your old records and fetching the new ones. There's no central "push" mechanism. There's no propagation queue. And there's no way to force it to happen faster after the fact.

Understanding how propagation actually works gives you the ability to plan changes that minimize downtime, predict when changes will take effect, and diagnose why some users see the update while others don't.

How DNS Resolution Works (The Short Version)

Before understanding propagation, you need to understand the resolution chain. When someone types your domain into their browser, a series of DNS lookups happen:

  1. The browser checks its own cache
  2. The operating system checks its local resolver cache
  3. The query goes to a recursive resolver (usually provided by the user's ISP, or a public resolver like Google's 8.8.8.8 or Cloudflare's 1.1.1.1)
  4. The recursive resolver, if it doesn't have the answer cached, walks the DNS hierarchy: root servers, then TLD servers (.com, .net, etc.), then your domain's authoritative nameservers
  5. Your authoritative nameserver returns the record along with a TTL (Time to Live) value
  6. Every resolver in the chain caches the answer for the duration of that TTL

That final point is the key to everything. Once a resolver caches your DNS record, it won't ask your authoritative nameserver again until the TTL expires. If your A record has a TTL of 3600 seconds (one hour), a resolver that just cached it will serve the old IP address for up to one hour, regardless of what you change on your authoritative nameserver.

What "Propagation" Actually Is

DNS propagation is not a broadcast or replication mechanism. Nothing is being "pushed" to resolvers around the world. Instead, propagation is the process of old cached records expiring across the thousands of recursive resolvers that have cached your domain's records.

Think of it this way: imagine every public library in the world has a photocopy of your business card. You update your phone number, but you can't recall all the old copies. Instead, each library has a rule: "throw away the photocopy after X hours and get a fresh one next time someone asks." Propagation is the time it takes for all those libraries to throw away their old copies and pick up the new one.

This is why propagation isn't instantaneous: different resolvers cached your record at different times, so their copies expire at different times. A resolver that cached your record 5 minutes ago will hold onto it for nearly the full TTL. A resolver that cached it 59 minutes ago (with a 60-minute TTL) will refresh almost immediately.

Why People Say "Up to 48 Hours"

You've probably seen the advice: "DNS changes can take up to 24-48 hours to propagate." This is technically true in the worst case, but it's misleading for most situations.

The 48-hour figure comes from the maximum TTL values that some registrars and DNS providers set by default, particularly on NS (nameserver) records at the TLD level. If you're changing nameservers for your domain (for example, moving from GoDaddy DNS to Cloudflare), the old NS records at the .com registry might have a TTL of 48 hours. Until those expire, some resolvers will still ask the old nameservers for your records.

For most record changes (A records, CNAME records, MX records) where you're not changing nameservers, propagation depends entirely on the TTL you set. A record with a 300-second (5-minute) TTL will propagate to most resolvers within 5-10 minutes. A record with a 86400-second (24-hour) TTL will take up to a day.

The Layers of Caching

Propagation delays come from multiple layers of caching, each with its own behavior:

Browser Cache

Modern browsers cache DNS lookups independently from the operating system. Chrome, for example, maintains its own DNS cache with entries typically lasting around 60 seconds. Even after the system-level cache has expired, the browser might still serve a stale answer.

To bypass this, you can clear your browser's DNS cache. In Chrome, navigate to chrome://net-internals/#dns and click "Clear host cache."

Operating System Cache

Your operating system maintains a DNS resolver cache. On Windows, you can flush it with ipconfig /flushdns. On macOS, use sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On Linux, it depends on your resolver (systemd-resolved: sudo resolvectl flush-caches).

Recursive Resolver Cache

This is the biggest factor. Your ISP's resolver, Google's 8.8.8.8, or Cloudflare's 1.1.1.1 all cache records according to the TTL. You have no control over when they refresh short of waiting for the TTL to expire.

CDN and Proxy Caches

If you're behind a CDN, the CDN itself may cache your origin's DNS resolution. Some CDNs refresh origin DNS on their own schedule, which can add latency to propagation even after the public DNS has updated.

Application-Level Caches

Some applications, particularly Java-based services, cache DNS lookups aggressively (Java's default is to cache successful lookups forever in some configurations). This can cause servers to continue connecting to old IPs long after public DNS has propagated.

TTL: The One Setting That Controls Everything

TTL (Time to Live) is the single most important factor in DNS propagation speed. It's specified in seconds and tells recursive resolvers how long to cache the record before requesting a fresh copy.

Common TTL Values

  • 60 seconds (1 minute): Very aggressive. Changes propagate quickly, but your authoritative nameservers handle significantly more queries. Used during active migrations.
  • 300 seconds (5 minutes): Good balance for records that change occasionally. Most DNS providers use this as a default.
  • 3600 seconds (1 hour): Standard for stable records. Reduces query load while still allowing reasonably fast changes.
  • 86400 seconds (24 hours): Common for records that rarely change (NS records, MX records for established mail infrastructure). Changes take up to a full day to propagate.

The Critical Mistake: Not Lowering TTL Before a Change

This is the most common DNS migration error. If your A record has a TTL of 86400 (24 hours) and you change the IP address, resolvers that just cached the old record will serve it for up to 24 hours. The change you made right now won't reach everyone for a full day.

The fix is simple but requires planning ahead: lower the TTL well before you make the actual change.

Here's the process:

  1. At least 48 hours before your migration: Lower the TTL on the records you plan to change to 60-300 seconds. This ensures that by the time you make the actual change, no resolver is caching your records for longer than 5 minutes.
  2. Wait for the old TTL to expire: If the TTL was previously 86400 seconds, wait at least 24 hours after lowering it. Otherwise, some resolvers still have the old TTL cached and will hold onto the old record for the original duration.
  3. Make your change: Update the record to the new value. Since the TTL is now 60-300 seconds, propagation completes within minutes.
  4. After the migration is confirmed: Raise the TTL back to your normal value (3600 or higher) to reduce query load.

This four-step process is the difference between a five-minute migration and a 24-hour migration. Plan ahead and TTL works for you. Skip the preparation and you're stuck waiting.

How to Check Propagation Status

You don't need command-line tools or technical expertise to check how your DNS records are resolving. DNS Assistant provides free tools that give you instant visibility.

DNS Assistant Free DNS Lookup

Head to dnsassistant.com/tools and run a DNS lookup on your domain. You can query all record types or a specific one (A, AAAA, MX, TXT, NS, CNAME, SOA, and more). The results show you exactly what's being returned, including the current TTL value, so you can see how long until the next cache refresh.

This is the fastest way to verify whether a change you made is live, check what TTL values are currently set, or confirm that a record exists before launching a new service (to avoid negative caching).

Free Domain Risk Report

For a deeper look, use the Free Domain Risk Report. Enter your domain and email address, and DNS Assistant will scan your DNS records, WHOIS registration, email authentication (SPF, DKIM, DMARC), and TLS configuration, then deliver a branded PDF report to your inbox.

This is particularly useful before a migration: run the report to establish a baseline of your current DNS configuration, make your changes, then run it again to verify everything updated correctly. The report flags misconfigurations like missing SPF records, expiring certificates, and vulnerable subdomains that you might not catch with a simple lookup.

Continuous Monitoring (Paid)

Free tools give you point-in-time checks. For ongoing visibility, DNS Assistant's monitoring platform continuously tracks your DNS records and alerts you when changes are detected. During a migration, you'll see exactly when each record updates. For day-to-day operations, you'll catch unauthorized changes before they cause outages. Alerts are delivered via email, Slack, Microsoft Teams, webhooks, or SMS.

Nameserver Changes: A Special Case

Changing your domain's nameservers (NS records) is fundamentally different from changing individual records. When you update NS records at your registrar, the change is made at the TLD level (the .com, .net, or .org registry). The TTL for NS records at the TLD level is typically set by the registry, not by you, and can be 24-48 hours.

During a nameserver change, there's a period where some resolvers ask the old nameservers and some ask the new ones. This means:

  • Both the old and new nameservers should serve correct records during the transition
  • Don't delete records from the old nameserver until propagation is complete
  • The transition can take up to 48 hours, and you can't speed it up by lowering TTLs on the old nameserver (the TLD-level NS record TTL is what matters)

Negative Caching: When "Record Not Found" Gets Cached

Here's a scenario that catches people off guard: you forget to create a record before launching a service. Someone tries to access the subdomain, the resolver queries your nameserver, and gets an NXDOMAIN (non-existent domain) response. That NXDOMAIN response gets cached too, based on the SOA record's minimum TTL field.

Now even after you create the record, that resolver will continue to return NXDOMAIN until the negative cache expires. This is defined in RFC 2308 and is one of the most frustrating propagation-related issues because the record exists on your nameserver, but certain resolvers insist it doesn't.

The fix is to always create DNS records before they're needed, not after. If you're launching a new subdomain, create the record hours before the launch to avoid negative caching.

Common Propagation Myths

Myth: "DNS propagation takes 24-48 hours"

Reality: Propagation time depends on your TTL. With a 300-second TTL, most of the internet will see your change within 10 minutes. The 24-48 hour figure only applies to nameserver changes or records with very high TTLs.

Myth: "I can speed up propagation by flushing my local DNS"

Reality: Flushing your local cache only affects your machine. It doesn't affect any other resolver on the internet. You'll see the change sooner, but everyone else is still waiting for their caches to expire.

Myth: "DNS providers can push changes to resolvers"

Reality: There's no mechanism for authoritative nameservers to notify recursive resolvers of changes. Resolvers only check back when their cached copy expires. The only exception is if you use a resolver that supports DNS push notifications (extremely rare).

Myth: "My change didn't propagate — something is broken"

Reality: Usually, you just need to wait. Run a DNS lookup at dnsassistant.com/tools to check the current TTL on cached records. If the TTL is counting down, the resolver will refresh when it hits zero. If you see inconsistent results across resolvers, that's normal during propagation.

Best Practices for DNS Changes

  1. Plan ahead. Lower TTLs at least 48 hours before any migration. This is the single most impactful thing you can do.
  2. Use low TTLs for records that change. A records for application servers benefit from 300-second TTLs. There's no reason to cache them for 24 hours.
  3. Use high TTLs for stable records. NS records, MX records for established mail infrastructure, and SPF records that rarely change can safely use 3600-86400 second TTLs.
  4. Create records before they're needed. Avoid negative caching by creating DNS records hours before a launch.
  5. Don't delete old records immediately. After a migration, keep old records active for at least one full TTL cycle before removing them.
  6. Monitor your changes. DNS Assistant tracks all record changes and shows you exactly what's happening across resolvers, eliminating the guesswork from propagation.
  7. Document your TTL strategy. Know what TTLs are set on your critical records so you can estimate propagation time before making changes.

When Propagation Isn't the Problem

Sometimes what looks like a propagation delay is actually a different issue:

  • Typo in the new record: The change propagated fine, but the new IP is wrong. Run a DNS lookup to verify what's being returned.
  • Wrong record type: You updated the A record but the CNAME record is overriding it, or vice versa.
  • CDN cache: DNS propagated, but your CDN is still caching the old origin. This is a CDN-level issue, not a DNS issue.
  • Local hosts file: An entry in /etc/hosts or C:\Windows\System32\drivers\etc\hosts overrides DNS entirely.
  • Unauthorized change: Someone else modified your DNS records, and what you're seeing is their change, not yours. This is exactly what DNS monitoring catches.

How DNS Assistant Helps

DNS Assistant turns DNS propagation from a guessing game into an observable process:

  • Continuous monitoring: Every record type tracked on your schedule, with alerts when values change
  • Change detection: Know immediately when a record changes, whether you made the change or someone else did
  • TTL tracking: See the TTL values across all your records so you can estimate propagation time before making changes
  • Historical records: See what your records were before a change, making it easy to roll back if something goes wrong
  • Multi-channel alerts: Get notified via email, Slack, Microsoft Teams, webhooks, or SMS the moment a change is detected

Whether you're planning a migration and need to verify propagation, or you need to catch unauthorized changes before they cause an outage, DNS Assistant gives your team the visibility to manage DNS with confidence.

Start with a free scan: Run a DNS lookup to check your current records, or get a comprehensive Free Domain Risk Report covering DNS, WHOIS, email authentication, and TLS.

For continuous monitoring, sign up at dnsassistant.com and take the guesswork out of DNS.

Start Monitoring Your DNS Today

Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.

Sign Up Free