Global DNS Propagation: How Anycast Resolvers, TTL Caching, and Root Servers Work in 2026
A DNS change is not a single worldwide switch. The authoritative server can answer with the new address immediately, while a resolver on another network keeps the previous answer until its cache expires. That gap is the propagation delay people see after they edit an A, AAAA, MX, CNAME, TXT, or NS record.
The hierarchy that actually answers
A recursive resolver does not store every name on earth. It walks a chain. Root servers point at the top-level domain. The TLD points at the domain's authoritative nameservers. Those nameservers hold the record you edited. Anycast lets many machines share one well-known address, such as 1.1.1.1, 8.8.8.8, or 9.9.9.9, so the nearest healthy node answers. Each of those nodes keeps its own cache.
Why TTL decides the delay
The time-to-live on a record tells a resolver how long it may reuse an answer. A 300-second TTL can turn over in minutes. A 86400-second TTL can keep the old address for a day even after the authoritative zone is correct. Lowering the TTL before a migration, waiting out the old value, and then changing the record is the practical way to shorten that window. Raising it again afterward reduces query load.
Flushing one cache does not flush the world
Clearing the resolver on a laptop, or running a local flush, drops only that computer's cache. It does not expire Cloudflare, Google, Quad9, or an ISP resolver. A propagation check has to ask those public resolvers separately and compare the answers. Different addresses at the same moment are normal during the TTL window. They are not proof that the zone failed to save.
Seoffix compares Cloudflare, Google, and Quad9 for one record type at a time. Use the global DNS propagation checker for an A, AAAA, MX, CNAME, TXT, or NS lookup, and the domain tools when you also need registration data. Registration and expiry come from RDAP, which is a different question from "what address is cached right now."
What to check before you call a change done
- Confirm the authoritative nameservers listed at the registry are the ones you edited.
- Read the TTL you published, not the TTL you hoped to publish.
- Compare at least three public resolvers, then check again after the TTL.
- Treat a mail or site outage during that window as cached data, and keep the old target alive until the long caches expire.
The same comparison is available to desktop agents through the Seoffix MCP server as seoffix_check_dns_propagation. The remote endpoint is https://seoffix.com/api/mcp.