DNS Propagation Guide: How Long It Takes and How to Check It

DNS propagation ends when the last resolver's cached copy of the old record expires, so the worst case is that record's TTL: a 3600-second TTL puts the change everywhere within 1 hour. 3 timers set the wait: the record TTL, the negative-cache TTL for a name that did not exist, and a delegation TTL of up to 48 hours on a nameserver change. UpMonitor's DNS probe resolves the hostname and fails on NXDOMAIN or an empty answer. The wait runs longer, if a resolver serves stale data.

What Is DNS Propagation?

DNS propagation is the window between editing a record on your authoritative nameserver and the moment every recursive resolver answers with the new value. A resolver, also called a recursive nameserver, stores each answer it fetches for the number of seconds in the record's TTL field. RFC 1035 defines that field as the time interval the record can be cached before the source is consulted again. Propagation is cache expiry, not distribution. The TTL is a ceiling, not a promise: RFC 2181 calls it a maximum time to live, not a mandatory one, and caps it at 2147483647 seconds.

How Long Does DNS Propagation Take?

DNS propagation takes at most the TTL the old record carried when each resolver cached it, and the type of change decides which TTL that is. The 6 change types and the timer behind each:

The "24 to 48 hours" rule of thumb fits nameserver changes only: TLD operators hardcode the glue-record TTL to 172800 seconds, and domain owners cannot change it. For a record edit, plan around the TTL you set. Probe the hostname with the free DNS propagation checker to confirm it resolves.

How DNS Propagation Works: The 4 Stops Between Your Edit and a Visitor

A DNS change reaches a visitor only after it clears 4 stops in the lookup path, and each stop holds its own copy on its own clock. The 4 stops, from your DNS provider outward:

1. Your authoritative nameservers publish the edit. A primary tells its secondaries with a NOTIFY message (RFC 1996); a secondary without NOTIFY polls at the SOA REFRESH interval, so 2 of your own nameservers disagree for up to that long.
2. The recursive resolver's cache expires. Your ISP's resolver, Google Public DNS or Cloudflare's 1.1.1.1 answers from cache until the TTL it stored runs out, then asks your nameserver again. Each resolver cached the record at a different moment, so each one flips at a different moment, and that scatter is what a propagation map shows.
3. The operating system's cache expires. Windows keeps a DNS client resolver cache that ipconfig /displaydns prints. macOS keeps its cache in mDNSResponder, and Linux distributions that run systemd-resolved keep one there.
4. The application opens a new connection. An open connection to the old IP address stays on it until it closes, so a long-open browser tab sees the change last.

Verify in the same order: the authoritative answer first, public resolvers second, your own machine last.

Why Do Some Resolvers Still Show the Old Record?

A resolver shows the old record past the TTL you expect for 1 of 5 reasons, and only the first is fully under your control:

• The old TTL was long. Resolvers stored the old record together with its old TTL, so a record that carried 86400 stays cached for up to 1 day after the edit, whatever TTL the new record carries.
• The name was cached as missing. A lookup that hit NXDOMAIN before you created the record is cached for the negative-cache TTL, which RFC 2308 takes from the lower of the SOA MINIMUM field and the SOA record's own TTL.
• The resolver enforces a minimum TTL. Unbound's cache-min-ttl option keeps data cached longer than the domain owner intended; it defaults to 0, off, until an operator sets it.
• The resolver serves stale data. RFC 8767 lets a resolver answer with expired records when your nameservers cannot be reached, suggests a stale limit of 1 to 3 days, and recommends a 30-second TTL on each stale answer.
• The delegation still points at the old provider. After a nameserver change, resolvers keep the TLD's delegation for up to 48 hours and send queries to the old provider's nameservers until it expires.

How to Check DNS Propagation in 4 Steps

Check DNS propagation by comparing the answer your authoritative nameserver gives with the answers public resolvers hold. The 4 steps, shown for www.example.com:

Step 1. Find the authoritative nameservers. Ask for the domain's NS set:

dig +short NS example.com

Step 2. Query 1 authoritative nameserver directly. The @server argument names the server to ask, so the answer skips every cache. Use a name step 1 printed:

dig @hera.ns.cloudflare.com www.example.com A +noall +answer

If this answer still shows the old value, the edit never reached the zone, and waiting will not fix it.

Step 3. Query 2 public resolvers. Compare Google Public DNS and Cloudflare 1.1.1.1 with the authoritative answer:

dig @8.8.8.8 www.example.com A +noall +answer
dig @1.1.1.1 www.example.com A +noall +answer

The second column is the TTL: the seconds the cache that answered has left on its copy. On Windows, Resolve-DnsName -Name www.example.com -Type A -Server 8.8.8.8 prints the same fields.

Step 4. Trace the delegation after a nameserver change. The +trace option follows the delegation path from the root servers with iterative queries, so it shows which nameservers the TLD hands out right now:

dig +trace www.example.com

Run steps 2 and 3 again once the old TTL has passed. When every answer matches the authoritative one, propagation is done; confirm it from outside your own network with the DNS checker.

How to Flush Your Local DNS Cache

Flushing your local DNS cache deletes the copy on your own machine; it does not touch your ISP's resolver or any other resolver on the internet. The command for each platform, plus the 2 public resolvers that accept flush requests:

Flush a public resolver only after step 2 above returns the new value, or it caches the old one again. Google adds 1 rule: after a registrar or DNS hosting change, flush the main domain name before its subdomains.

How to Speed Up DNS Propagation Before a Change

Speed up DNS propagation by lowering the TTL at least 1 old TTL before the change, because every resolver keeps the old TTL until its cached copy expires. The 5-step cutover:

1. Lower the TTL to 300 seconds. Do it at least 1 old TTL ahead: 1 day ahead for a record at 86400, 1 hour ahead for a record at 3600.

2. Wait out the old TTL. Until it expires, a resolver that cached the record right before step 1 still holds it under the long TTL.

3. Change the record. Every resolver that honors the TTL now refetches within 300 seconds, 5 minutes.

4. Keep the old server answering. Leave it running for at least 1 TTL after the change, longer for resolvers that serve stale data, and install the TLS certificate for the hostname on the new server before the switch. The guide to decode SSL certificate errors covers the name-mismatch warning a missing certificate produces.

5. Raise the TTL again. Restore the normal value once every resolver you checked returns the new record, so resolvers stop refetching every 5 minutes.

A nameserver change cannot be shortened this way, because the 48-hour delegation TTL belongs to the TLD. Keep the old provider serving an identical zone for 48 hours, if you want no visitor to hit a gap.

Does DNSSEC Slow Down DNS Propagation?

No for a record edit, yes for a provider move. A signed zone adds the DS record, a digest of your zone's DNSKEY that RFC 4035 places in the parent zone, so it follows the parent's TTL, not yours. When the DS record still matches the old provider's key, a validating resolver cannot build the chain of trust, treats the answer as Bogus, and returns RCODE 2, SERVFAIL, to the client. Visitors behind validating resolvers then lose the domain while everyone else still reaches it. Audit both halves of the chain, the DNSKEY at the zone and the DS record at the registrar, with the free DNSSEC checker.

How to Fix 5 Common DNS Propagation Problems

Fix each problem at the layer that holds the stale copy, then probe the hostname again:

1. NXDOMAIN for a subdomain you created minutes ago. A resolver looked the name up before it existed and cached the negative answer. Wait out the negative-cache TTL, or flush the name at Google Public DNS and 1.1.1.1. Prevention: create the record and confirm it at the authoritative nameserver before you publish the URL anywhere.

2. The authoritative nameserver still returns the old value. The edit went to a zone nobody queries: a record changed at the registrar while the NS set points at a different DNS host. Compare dig +short NS example.com with the provider you edited, then make the change at the host the NS set names. Prevention: keep DNS at 1 provider and delete the unused zone.

3. A single public resolver disagrees after the TTL has passed. That resolver enforces a minimum TTL or serves stale data. Flush it through its operator's form, 1 name and 1 record type per request. Prevention: lower the TTL a full old-TTL period before the change.

4. SERVFAIL right after a DNS provider move. The DS record at the registrar still matches the old provider's DNSKEY, so validating resolvers reject every answer. Replace it with the DS record the new provider publishes. Prevention: remove the DS record and wait out its TTL before you switch nameservers, then publish the new provider's DS record once it signs the zone.

5. The site loads on mobile data but not on your Wi-Fi. Your machine or your router still holds the old record, while the mobile network's resolver fetched the new one. Run the flush command for your platform, then restart the router if the old answer persists. Prevention: test from outside your own network before you call a change done.

How to Monitor DNS After a Change

Monitor DNS after a change by probing the hostname on a schedule. A record that resolved at cutover still breaks later through an expired domain, a provider error or an edited zone. UpMonitor's DNS probe resolves the hostname, measures the response time, and fails when the name returns NXDOMAIN, resolves to no address, or the query errors out with SERVFAIL or REFUSED. A monitor runs it every 300 seconds from 1 region on the Free plan, and as often as every 60 seconds from up to 6 regions on PRO or 12 on Agency. The same probe runs in a pipeline:

npx @upmonitor/cli check https://upmonitor.io --ci --fail-on failure --checks dns

The --checks dns flag keeps the gate on resolution, and a logged-in run takes --region <id> to probe from 1 specific region. The CLI documentation for CI exit codes lists the 3 exit codes: 0 when all checks passed, 1 when a check failed under --fail-on, and 2 on a configuration or network error. Run it after every DNS change, the way the website monitoring pipeline in CI/CD runs it after every deploy. A scheduled probe reports a resolution failure within 1 interval, before a visitor does.

Frequently Asked Questions

How long does DNS propagation take after changing nameservers?

Up to 48 hours, because TLD operators hardcode a 172800-second TTL on delegation glue and resolvers keep the old delegation until it expires. Keep the old provider serving an identical zone for the full 48 hours, and visitors see the same answer whichever provider their resolver reaches.

Can I speed up DNS propagation that has already started?

Only on the resolvers you can flush: your own machine, Google Public DNS and Cloudflare 1.1.1.1, 1 name and 1 record type at a time. Every other resolver keeps the old record until the TTL it stored runs out, whatever TTL you set now.

Does a low TTL slow down my website?

A low TTL adds lookups, not page weight. Each resolver refetches the record once per TTL period, so the first visitor after each expiry waits while the resolver asks your nameserver again, and everyone after that gets the cached answer. At 300 seconds that extra lookup happens at most once every 5 minutes per resolver, which fits a migration window.

Why does a DNS checker show different results in different locations?

Each location asks a different resolver, and each resolver cached your record at a different moment, so each drops the old copy at a different moment. Mixed results after the old TTL window point to a resolver with a minimum TTL or stale serving, or to 2 of your own nameservers that disagree.