Understanding DNS propagation

After a DNS change, two people sometimes see two different answers: one the new server, the other the old one. This is called propagation, while it is simply caches expiring at different times. The delay is predictable if you know the TTL.

What actually happens

Your change is stored immediately on the authoritative server. Then every resolver that already holds the old answer keeps it until its TTL ends. Nothing is broadcast to all resolvers worldwide.

Three layers may keep an answer:

• the ISP or company resolver;
• a public resolver such as 1.1.1.1 or 8.8.8.8;
• the local system, including systemd-resolved on Linux or the browser DNS cache.

Negative caching applies too: a "this name does not exist" error is remembered according to the SOA minimum field, often several minutes.

Realistic delays by TTL

Add delegation propagation time if you change DNS servers: the NS TTL at the extension applies, and some resolvers extend it.

The right sequence is to lower the TTL to 300 at least 24 hours ahead (ideally 48 hours, to let the old TTL expire), then make the change.

Verify without fooling yourself

First query the authority, which holds the truth:

dig @ns1.provider.com A your-domain.com +short

Then public resolvers, to see what visitors see:

dig @1.1.1.1 A your-domain.com +short
dig @8.8.8.8 A your-domain.com +short

dig +trace shows delegation, useful when the NS records themselves changed. Websites showing a world map simply query many resolvers: they measure caches, not propagation.

To test a server without waiting for DNS, use curl --resolve:

curl -sI --resolve your-domain.com:443:[YOUR_IPV6] https://your-domain.com/ | head -n 5

Flush local caches

If your machine still shows the old address while public resolvers are current, flush the local cache.

On Debian with systemd-resolved:

sudo resolvectl flush-caches
resolvectl status

With unbound or dnsmasq, restart the matching service. On macOS, use sudo dscacheutil -flushcache then sudo killall -HUP mDNSResponder. On Windows, ipconfig /flushdns. Browsers may keep an internal DNS cache: test in a private window or restart the browser.

Good practice

• Do not change the TTL and the record value at the same instant: do it in two steps.
• Keep the old server online until the TTL expires, or visitors still on the old address hit an error.
• Change mail records during a quiet period and watch for rejections for 48 hours.
• Write down the change time and the TTL you applied: the next diagnosis becomes trivial.