DNS Propagation Time: Calculate It Instead of Waiting 48h

“Allow up to 48 hours for changes to propagate” appears in nearly every DNS support reply. It isn’t wrong. It’s just far too high for most changes, and once you know where the number comes from you can work out when your own change will be visible to the minute.

What “propagation” really means

The word suggests your change is being pushed around the internet. It isn’t. The moment you save a record, it’s on your provider’s authoritative nameservers, give or take a few seconds of internal sync.

What takes time is forgetting. Every resolver that looked up your name before the change may keep that answer for as long as its TTL allows. Only then does it ask again. So DNS propagation is really cache expiry, and cache expiry is predictable.

How long DNS propagation actually takes

There are four cases, with very different timings.

The .com figures come straight from Verisign’s servers and you can check them yourself:

dig @a.gtld-servers.net google.com NS +norecurse +noall +authority

google.com.		172800	IN	NS	ns1.google.com.
google.com.		172800	IN	NS	ns2.google.com.

172800 seconds is 48 hours. That’s where the famous number comes from. Other TLDs set their own values. Germany’s .de, for instance, uses 86400, so the same query against its servers shows one day.

The negative TTL nobody thinks about

A common trap: you create app.example.com, open it right away, it fails because of a typo, you fix the record, and the name still won’t resolve. Your resolver cached the “doesn’t exist” answer.

How long it keeps that answer is defined in the zone’s SOA record. Per RFC 2308 it’s the lower of the SOA record’s own TTL and its last field:

dig example.com SOA +noall +answer

example.com.	3600	IN	SOA	ns1.example-dns.net. hostmaster.example.com. 2026101801 7200 3600 1209600 3600

Here that’s 3600 seconds. Create the record first and test afterwards, and you never hit this.

Check propagation without a world map

Online checkers show pretty maps but rarely tell you why a resolver still has the old answer. dig does. Ask the authoritative server first, then the big public resolvers:

dig @ns1.example-dns.net example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer

example.com.		2412	IN	A	198.51.100.7

That 2412 is how many seconds the answer has left in that resolver’s cache. In about 40 minutes it will ask again. If the authoritative server already returns the new value, there’s nothing left to fix.

For nameserver changes, dig +trace walks the delegation from the root itself and bypasses caches:

dig +trace example.com NS

When it’s still old after the TTL has passed

Then it’s one of these, roughly in order of how often I see them:

1. Local cache. resolvectl flush-caches on Linux with systemd-resolved, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, ipconfig /flushdns on Windows. Chrome has its own cache at chrome://net-internals/#dns.
2. You edited the wrong zone. The domain’s nameservers point somewhere else. Compare dig NS example.com +short with the provider you edited.
3. Resolvers that ignore TTLs. Some ISP resolvers hold records longer than allowed. You can’t fix that, only work around it by keeping the old server running for a while.
4. A minimum TTL at the resolver. Some resolvers enforce a floor, so your 60 seconds effectively become several minutes.

Google Public DNS and Cloudflare 1.1.1.1 both have web forms to purge a single name from their cache. Useful for testing, irrelevant for your visitors.

Nameserver changes and DNSSEC

If the domain is signed with DNSSEC, the TLD zone holds a DS record that refers to your current provider’s key. Switch nameservers without updating or removing that DS record and validating resolvers return SERVFAIL. The domain doesn’t propagate slowly, it disappears for a large share of users.

dig example.com DS +short

If that returns a line, disable DNSSEC with the old provider first, wait until the DS record is gone from the TLD and its TTL has passed, switch nameservers, then enable DNSSEC with the new provider. Record changes inside the same zone aren’t affected, because your provider re-signs them.

What happens during the overlap

While old caches live, both servers get traffic. For a static site that’s harmless. For an app with a database, users write to the old server during that window and those writes never reach the new one. The usual fix is to turn the old server into a proxy for the new one right after the switch, as described in server migration without downtime.

Plan the propagation before you change anything

The real trick is to make propagation short before the change. An A record with a TTL of 86400 can’t be switched quickly. Lower it to 300 a day in advance and the actual change takes five minutes at most. The details are in the DNS TTL guide.

For certificates, remember that Let’s Encrypt resolves through its own resolvers, not your ISP’s or your laptop’s cache. What your machine sees is no indication of what validation will see. Once the authoritative server has your new A record and the old TTL has expired, request the certificate.

At betadomain you set A, AAAA and MX records in the customer area and choose the TTL per record. If you need a fresh name, the domain availability search gives you an answer in seconds. A .com domain is €14.99 a year, a .co.uk €15.99, and both renew at the same price.