When you change DNS records (NS servers, A record, MX), the changes do not apply instantly. DNS servers around the world keep cached records for the time specified in the TTL.

Typical DNS Propagation Times

Change Type	Minimum	Typical	Maximum
NS server change	30 min	4–8 hours	48–72 hours
A record change	5 min	1–4 hours	24 hours
MX record change	5 min	1–4 hours	24 hours
New CNAME/TXT	5 min	15–60 min	4 hours

💡 Lower the TTL to 300 seconds 24 hours before the planned change — then the update will propagate within 5 minutes.

Why DNS Does Not Propagate Instantly

Every DNS server caches records for the TTL (Time-To-Live) period. Until the TTL expires, the server returns the old value from its cache instead of requesting an update from the authoritative DNS.

Checking DNS Propagation

dig (Linux/Mac)

# Check the A record
dig example.com A

# Through a specific DNS server (Google)
dig @8.8.8.8 example.com A

# Through Cloudflare DNS
dig @1.1.1.1 example.com A

# Check the NS records
dig example.com NS

nslookup (Windows/Linux)

nslookup example.com 8.8.8.8

Online Services

dnschecker.org — checks from 100+ locations worldwide
whatsmydns.net — propagation map
mxtoolbox.com — MX record checker

Speeding Up DNS Propagation

# Flush the DNS cache on Windows
ipconfig /flushdns

# On macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# On Ubuntu/Debian
sudo systemd-resolve --flush-caches

⚠️ Flushing the cache only helps on your own device. Other providers' servers will wait for the TTL to expire.

Common Error Messages When Checking DNS

dig/nslookup Response	What It Means	What to Do
`;; connection timed out; no servers could be reached`	The specified DNS server is unreachable or blocked by the network firewall	Try a different public resolver (1.1.1.1, 8.8.8.8) and confirm UDP/53 isn't blocked
`NXDOMAIN`	The domain doesn't exist in this zone — it's either unregistered or there's a typo in the name	Double-check the domain spelling and its registration status via whois
`SERVFAIL`	The domain's authoritative DNS server isn't responding correctly — a zone error or the server is down	Check the domain's NS servers and the zone configuration on the DNS provider's side
NOERROR, but the ANSWER SECTION is empty	The zone exists and responds, but no record of the requested type exists for that name	Confirm the record was created with the exact type you need (for example, you're querying AAAA, but only an A record was created)

What NOERROR with an Empty ANSWER SECTION Means

This is not a propagation error — the resolver successfully reached the domain's authoritative server and got the answer "no record of this type exists." Waiting won't help here: you need to create the record, not wait out the TTL.

When DNS Won't Update on Time Even If Everything Was Done Right

The ISP's resolver caches records longer than the declared TTL — this happens with some mobile carriers that round TTL to their own internal values
The old hosting's NS servers are switched off before the TTL expires — resolvers that haven't refreshed their cache yet will get an error instead of the new value
A corporate DNS server is configured with its own forced TTL regardless of the authoritative answer
Some public Wi-Fi and ISP DNS servers don't clear the cache for popular "warmed-up" domains for years — the only workaround for a user is to switch the DNS server manually to 1.1.1.1 or 8.8.8.8

DNS Cache Layers and Their Typical Lifetime

Cache Layer	Typical Lifetime	How to Clear It
Browser cache	About 60 seconds in most modern browsers	Restart the browser or clear its DNS cache in settings
Operating system cache	Equal to the record's TTL, but at least a few seconds	`ipconfig /flushdns` (Windows), `systemd-resolve --flush-caches` (Linux)
ISP resolver cache	Equal to the record's TTL, sometimes longer at large ISPs	Cannot be flushed by the user — only switching to a different resolver (1.1.1.1, 8.8.8.8)
Secondary DNS server cache	Set by the Refresh field in the zone's SOA record, typically 3600–86400 seconds	Configurable only by the zone owner via the SOA record

Full propagation only finishes once every cache layer has expired at the same time — so the real-world time is often longer than the single TTL shown on the record.

In practice, a useful rule of thumb: if even part of the resolvers still return the old record after twice the old TTL has passed, the problem isn't propagation — it's a configuration issue (for example, the old A record was never removed, or the old hosting's NS servers are already unreachable). That two-TTL margin covers nearly every case of rounding and re-checking on the resolver side, and it's what should go into a migration plan instead of the single TTL value from the documentation.