How DNS Propagation Works: TTL, Caching, and Global Updates

What Is DNS Propagation?

DNS propagation is the time it takes for DNS changes — new records, updated IP addresses, nameserver changes — to become visible across the internet. When you change your domain's A record from one IP to another, the update isn't instantaneous. Instead, it ripples outward from your authoritative DNS servers through a hierarchy of caching resolvers, each respecting its own expiration timer.

This process can take anywhere from a few minutes to 48 hours, depending on your TTL (Time To Live) settings, the specific DNS record type, and whether you're changing records versus changing nameservers entirely. Understanding why this delay exists — and how to minimize it — is essential for anyone managing domains.

The DNS Resolution Chain

To understand propagation, you need to understand how DNS queries flow. When a user types example.com into their browser, the request passes through several layers, each of which may cache the result:

• Browser Cache: Modern browsers cache DNS results for a short period (typically 60-300 seconds). Chrome and Firefox also have their own internal DNS-over-HTTPS resolvers that may behave differently from the OS.
• OS Resolver: The operating system's DNS client caches results according to the TTL. On Linux, systemd-resolved handles this; on Windows, the DNS Client service.
• Recursive Resolver (ISP/Third-party): This is where most propagation delays occur. Your ISP's resolver (or public resolvers like Google 8.8.8.8, Cloudflare 1.1.1.1) caches DNS records aggressively. When you change a record, these resolvers won't know until their cached copy expires.
• Root and TLD Servers: These cache the delegation pointing to your authoritative nameservers. Changes at this level (switching nameservers) propagate more slowly because TLD caches have their own TTLs.
• Authoritative Nameservers: The source of truth. Your DNS provider (Cloudflare, Route53, etc.) serves records from here. Changes are effective immediately at this level.

TTL: The Key Variable

Every DNS record includes a TTL value — the number of seconds the record should be cached before being re-fetched. This is the single biggest factor in propagation speed:

• 3600 seconds (1 hour): Common default. Balanced — changes appear within an hour for most users.
• 86400 seconds (24 hours): Often found on older configurations. Changes take up to a day to fully propagate.
• 300 seconds (5 minutes): Used for records that change frequently (load balancers, failover setups). Faster propagation but more DNS queries.
• 60 seconds: Near-instant propagation. Some DNS providers support this; others have minimum TTLs.

The trick for planned migrations: lower your TTL 24-48 hours before making changes. Set it to 300 seconds, wait for the old TTL to expire across caches, then make your change. The new record propagates in minutes instead of hours.

Why Propagation Isn't Uniform

You might check your site from your phone and see the new server, while your laptop still hits the old one. This is normal — different devices use different DNS resolvers, and each cache expires on its own schedule.

Key factors creating non-uniform propagation:

• Resolver Choice: Google DNS (8.8.8.8) might have your old record cached for 2 more hours, while Cloudflare DNS (1.1.1.1) already fetched the update. Each resolver is independent.
• Record Type: A records propagate at their own TTL. MX records have separate TTLs. NS records and SOA records have their own timers. Changing nameservers is the slowest because you're dealing with TTL caches at the registry level.
• Negative Caching: If a resolver queried your domain before the record existed (NXDOMAIN), it caches the negative response for the SOA minimum TTL. This is why newly created subdomains sometimes take extra time — resolvers that previously checked and found nothing remember that "nothing" for hours.
• Geo-distributed Caches: Large DNS providers like Google and Cloudflare have hundreds of resolver nodes globally. The node in Singapore might expire the cache before the one in Frankfurt, creating regional inconsistencies.

Nameserver Changes vs Record Changes

There are two fundamentally different types of DNS changes, and they propagate at very different speeds:

• Record Changes (same provider): Changing an A record, adding a TXT record, modifying an MX — these changes are instant at your authoritative server. Propagation depends purely on how quickly caches expire. With a 1-hour TTL, most of the world sees the change within 1-2 hours.
• Nameserver Changes (switching providers): When you change which nameservers are authoritative for your domain (e.g., moving from your registrar's DNS to Cloudflare), the update must propagate through the TLD registry. The TLD's own TTL applies — typically 24-48 hours. During this transition, some queries hit old nameservers, some hit new ones. This is why migrations are scheduled during low-traffic periods with both old and new DNS configured identically.

How to Check Propagation Status

Don't guess — verify. Several methods help you track propagation in real-time:

• DNS Lookup from Multiple Resolvers: Query your domain through different DNS providers and compare results. Our DNS Lookup tool queries authoritative servers directly, bypassing caches. Use it alongside a resolver-based check to see what cached vs live.
• Global Propagation Checkers: Services like whatsmydns.net query your domain from dozens of locations worldwide and show a map of which resolvers have the new record vs the old one.
• Dig with Specific Resolvers: dig @8.8.8.8 example.com queries Google DNS directly. dig @1.1.1.1 example.com hits Cloudflare. Compare results to track propagation.
• Check TTL Remaining: dig example.com shows the remaining TTL in the answer section. If you see your 300s TTL showing 240s, the record was cached 60 seconds ago. If it shows your full TTL, the cache just refreshed.

Common Propagation Problems

• Forgot to Lower TTL: The #1 mistake. If your TTL was 86400 (24h) when you made the change, some users will see the old record for a full day. Always lower TTL 24h before planned changes.
• DNSSEC Misconfiguration: If DNSSEC is enabled and you switch nameservers without updating DS records at the registrar, the domain will fail to resolve for resolvers that validate DNSSEC (most modern ones do).
• SOA Serial Not Incremented: If you're running your own DNS server (BIND, PowerDNS) and forget to increment the SOA serial number after a change, secondary servers won't transfer the updated zone. The authoritative server has the new record, but secondaries serve stale data.
• ISP Resolver Ignoring TTL: Some ISPs override TTLs with their own minimums. This is non-compliant behavior but it happens. If one specific ISP's users can't see your changes, this is likely why.