What Is DNS Propagation? Why Record Changes Take Time
DNS propagation is the window after you change a DNS record during which different resolvers still serve the old value until their cached copies expire.
When you update a DNS record, the change is not instant everywhere. Resolvers around the world cached the old answer for its TTL and will keep returning it until that timer runs out. Deploys that involve a DNS cutover, like pointing a domain at a new host, must account for this delay or they appear half-broken.
Caching causes the delay
Resolvers cache records for the TTL the authoritative server specified. After a change, each resolver keeps serving the old value until its cache entry expires, so the new value rolls out gradually.
TTL controls the speed
- Low TTLs make changes propagate quickly.
- High TTLs are efficient but slow to update.
- Lowering TTL before a planned cutover speeds it up.
Inconsistent answers during the window
While propagating, some clients see the new record and others see the old one. A deploy verified from one location may look fine while users elsewhere still hit the old host.
Propagation in deployments
A cutover that changes an A or CNAME record can leave the site intermittently pointing at old infrastructure until propagation completes. Pre-lowering the TTL and keeping the old host alive during the window avoids errors.
Verifying a cutover in CI
A pipeline that checks the new endpoint right after a DNS change may resolve the stale address and fail. Waiting for the TTL or querying the authoritative server directly gives a reliable answer.
Transient lookups during propagation
Resolution can be inconsistent mid-propagation, producing intermittent failures that are not real outages. Latchkey runners retry transient resolution failures to common endpoints, smoothing over brief inconsistency during a cutover.
Key takeaways
- DNS propagation is the lag before a record change is seen everywhere as caches expire.
- TTL controls the speed, so lower it before a planned cutover.
- Mid-propagation answers are inconsistent, which can cause flaky deploy checks.