Network guides
DNS Propagation Explained: Why Your DNS Change Takes Time
When you change a DNS record, you expect it to take effect immediately. In practice it often does not, and the delay is not a bug - it is the system working as designed. DNS is built on caching, so every resolver that has already looked up your domain keeps the old answer until it decides to check again.
In this guide we look at why propagation takes time, what the TTL value controls, how recursive resolvers store answers, and how you can verify a change from several independent points. Understanding this turns a confusing wait into a predictable process.
-
1983
DNS is specified
RFC 882 and RFC 883 define the Domain Name System, introducing a hierarchical and distributed name service for the internet.
-
1987
Caching and TTL are formalized
RFC 1034 introduces the Time To Live concept, telling resolvers how long they may keep an answer before checking the authoritative server again.
-
1990s
Recursive resolvers spread
ISPs and organizations deploy recursive resolvers that cache answers for their users, dramatically speeding up lookups but adding propagation delay.
-
Today
Public resolvers and faster checks
Large public resolvers like Google, Cloudflare and Quad9 add many independent caches to check, making propagation easier to observe from multiple points.
Why a DNS change does not appear everywhere at once
The internet does not resolve every domain by asking the source each time. Instead, recursive resolvers cache the answers they have already fetched and reuse them for a set period. When you change a record, the change is instant at the authoritative server, but every resolver that cached the old value keeps serving it until that value expires.
This is why a change seems to appear in some places and not others. The delay is not one uniform time - it is a patchwork of individual caches, each expiring at its own pace depending on when it last looked up your domain.
What the TTL value actually controls
TTL, or Time To Live, is the number of seconds a resolver may keep a cached answer before it must ask the authoritative server again. A high TTL, like 86400 seconds, means caches hold the old answer for a day. A low TTL, like 300 seconds, means they refresh after five minutes.
Lowering the TTL before a planned change is the standard way to make propagation fast. Set it low a day or two in advance, let the old caches drain, then make the change. After it settles you can raise the TTL back up to reduce load on the authoritative server.
Low versus high TTL: the trade-off
A low TTL means changes spread quickly, which is ideal for environments where records change often, such as failover setups or dynamic IPs. The cost is more queries hitting the authoritative server, since caches cannot hold answers for long and keep asking.
A high TTL means fewer queries and lower server load, which suits stable records that rarely change. The downside is that a mistake takes much longer to undo, because old caches will keep serving the wrong answer for the whole TTL period.
How to check propagation across multiple resolvers
To verify a change, query several independent recursive resolvers rather than trusting a single one. A tool that checks Google, Cloudflare and Quad9 at once gives you a much better picture than your own resolver, which may still be holding a stale cached value.
When the new record is visible from most public resolvers, propagation is essentially complete, even if a few small caches lag behind. If the change still looks stuck everywhere, check the authoritative server directly - a problem there is not a propagation issue at all.
要点总结
DNS propagation is a feature, not a bug: caching keeps the internet fast at the cost of a short delay after changes. Understand the TTL, lower it before a planned change, and verify with several resolvers so a wait becomes predictable rather than confusing.