How Long Does DNS Propagation Take?

DNS propagation takes as long as the old record's TTL (time to live): five minutes for a TTL of 300 seconds, a day for a TTL of 86400. A change of name servers can take up to two days, because the .com and .net registries publish each domain's name server list with a TTL of 172,800 seconds, which is 48 hours.

Those are upper limits for most resolvers, and many people see the new value sooner.

Check a change now Compare what Google, Cloudflare, OpenDNS, and Quad9 return for a domain's A record, with the TTL each has left.

What is DNS propagation?

Nothing is sent out across the internet when you change a DNS record. Your DNS provider's name servers, the authoritative servers for your domain, give the new answer as soon as the change is published on them. The delay comes from resolvers, the servers that look names up for everyone else (your internet provider's, or public ones such as 8.8.8.8). A resolver keeps each answer it fetches for the number of seconds in the record's TTL. RFC 1035 defines the TTL as "the time interval that the resource record may be cached before the source of the information should again be consulted".

Each resolver's copy expires at a different moment, so for a while some people get the old value and some the new one. That window is what "propagation" refers to.

How long does DNS propagation take for each kind of change?

• Changing an existing record (A, AAAA, CNAME, MX, TXT): up to the TTL the old record had. The new TTL does not matter to a resolver still holding the old copy.
• Adding a record for a name someone already looked up: up to the zone's negative-caching TTL, taken from its SOA record. RFC 2308 suggests one to three hours; example.com uses 30 minutes.
• Changing name servers: up to the TTL of the registry's delegation, plus however long resolvers hold the old provider's own NS records. Up to 48 hours for .com.

Why does a record change take as long as the old TTL?

A resolver that fetched the record one second before you saved the change holds the old value for the full TTL. A resolver that had nothing cached asks your name servers and gets the new value at once. Lowering the TTL in the same edit as the new value does not help, because resolvers holding the old copy still count down the old TTL.

You can watch the countdown. Asked for the same record at the same moment, four public resolvers each report how many seconds they have left:

The record's TTL at the source is 300. Google had fetched it moments earlier; OpenDNS will ask again in 49 seconds.

Resolvers that shorten or stretch the TTL

Resolver operators can apply their own limits to the TTL:

• Caps on long TTLs. Google Public DNS says cached records are "generally limited to six hours even if the actual TTL is longer". Asked for example.com's NS records, which carry a TTL of 86400 at the source, it answered with 21600. Unbound caps at one day by default (cache-max-ttl), and BIND at one week (max-cache-ttl).
• Floors on short TTLs. An operator can raise very short TTLs. Unbound's cache-min-ttl is off by default, and its manual warns that values above about an hour cause trouble. BIND's min-cache-ttl is also 0 by default and cannot exceed 90 seconds.
• Serving stale answers. RFC 8767 lets a resolver keep answering with expired data when it cannot reach a zone's name servers, and suggests keeping such data for one to three days. It matters when the old servers stop answering mid-move.

Browser and operating system caches

Most operating systems and browsers keep their own DNS cache, and a hosts file entry overrides DNS on that machine. To clear the caches:

• Windows: ipconfig /flushdns. Microsoft's documentation notes that this also discards negative entries.
• macOS: sudo killall -HUP mDNSResponder.
• Linux with systemd-resolved: resolvectl flush-caches.
• Chrome and other Chromium browsers: open chrome://net-internals/#dns and press "Clear host cache".

Why does a new record not show up yet?

Resolvers also remember that a name or record does not exist. This is negative caching, described in RFC 2308. If anyone looked the name up before you created it, resolvers keep that "no" for a time the zone sets: the lower of the SOA record's own TTL and its last field, the minimum. RFC 2308 says one to three hours has worked well and over a day has caused problems. dig shows the SOA in any negative answer:

For example.com both values are 1800, so a resolver may remember "does not exist" for up to 30 minutes. Resolvers can cap this as well: Unbound's cache-max-negative-ttl defaults to one hour, and BIND's max-ncache-ttl to three. Create records before anyone tests the name.

How long does a name server change take?

Moving a domain to a new DNS provider changes the delegation, the list of name servers the top-level domain's registry hands out. First, your registrar sends the new list to the registry, which publishes it in the TLD zone. ICANN's standard registry agreement for generic TLDs requires the registry's name servers to show the change within 60 minutes for at least 95% of its measurements. Country-code registries set their own rules.

Second, resolvers that already know your old name servers keep using them until their cached copy expires. The registry sets that TTL, and it varies. When this article was written, the registries answered with these values:

To see your own TLD's value, run the same command against one of its servers (dig +short NS com lists them). The 172,800 seconds used by .com and .net is where the familiar "up to 48 hours" comes from. Your old provider's zone also contains NS records, and a resolver that has seen them may keep those instead of the registry's list (RFC 2181 ranks a zone's own data above the registry's referral). example.com's own NS records have a TTL of 86400, so a resolver can follow them for a day. If your old provider lets you, lower the TTL on those NS records ahead of the move.

With DNSSEC, the DS record at the registrar must match the new provider's keys, or validating resolvers return SERVFAIL for the whole domain.

How can you make DNS propagation faster?

1. Lower the TTL ahead of time. Set the record's TTL to a few minutes, then wait at least as long as the old TTL so every cached copy with the long value has expired.
2. Make the change. A mistake can now be corrected within minutes.
3. Restore the TTL once the new value has been stable for a while. Short TTLs mean more queries to your name servers.
4. Keep the old side running. Leave the old server serving the site, and the old DNS provider serving the same records, until the change has settled everywhere.
5. Flush the caches you can reach. Google and Cloudflare each publish a page that clears a name from their public resolver: Google's Flush Cache (it cannot flush names that use client-subnet geolocation) and Cloudflare's Purge Cache. Nothing clears your internet provider's resolver or other people's computers.

How do you check DNS propagation?

Work from the source outward.

1. Ask the authoritative name server

Find the domain's name servers with dig +short NS example.com, then ask one of them directly. The aa flag means the server answered from its own zone data:

If the authoritative server does not show the new value, the change was not saved or was made at a provider the domain does not use.

2. Check the delegation

For a name server change, ask the registry, as in the dig +norec ... @a.gtld-servers.net example above, or look at the name servers in a WHOIS lookup. If the registry still lists the old servers, the change has not reached it yet.

3. Compare public resolvers

Run the loop shown earlier, or use the DNS Propagation Checker. A resolver still on the old value should switch when its remaining TTL reaches zero. One that keeps the old value well past the old TTL points to one of the resolver limits above, or to a delegation that has not moved.

4. Clear your own caches

If every resolver has the new value and your browser does not, the old answer is local. Flush it with the commands above, or try another device or network.

What does the HostChecker DNS Propagation Checker show?

The DNS Propagation Checker asks Google (8.8.8.8), Cloudflare (1.1.1.1), OpenDNS (208.67.222.222), and Quad9 (9.9.9.9) for a domain's A record at the same time, shows each answer with the TTL that resolver has left, and says whether they agree. For an IPv4 address it compares the reverse DNS (PTR) record instead. All four questions come from HostChecker's one server, so the result shows four resolvers from a single vantage point. It does not look up AAAA, MX, TXT, or NS records or query your authoritative name servers; for those, use dig as shown above, or the DNS Lookup, which shows eight record types through one resolver.

Common questions about DNS propagation time

Does DNS propagation always take 24 to 48 hours?

No. That figure comes from name server changes on TLDs such as .com, where the delegation TTL is 48 hours. A record change at a provider that uses a 300-second TTL reaches every resolver that honours the TTL within five minutes.

Why do I see the new site when other people do not?

You and they use different resolvers, each with its own copy of the record fetched at a different time. Your own computer or browser may also hold the old answer after the resolvers have moved on.

Does propagation affect email?

Yes. MX, SPF, DKIM, and DMARC records are cached by their TTL like any other record, and sending mail servers use their own resolvers. Keep the old mail server accepting mail until the old MX TTL has passed.

How do I check propagation of MX or TXT records?

Ask resolvers directly, for example dig @8.8.8.8 example.com MX or dig @1.1.1.1 example.com TXT. On Windows, use nslookup -type=MX example.com 8.8.8.8. For SPF, DKIM, and DMARC, the SPF, DKIM, and DMARC Checker reads the current records.