DNS Propagation: Why DNS Changes Don't Take Effect Instantly

Every web developer and administrator has faced this situation: you change a DNS record, but an hour (or even a day) later, some users still see the old site. This phenomenon is called DNS propagation — the process of distributing DNS changes across the entire global network. Let's explore why this happens and how to deal with it.

How DNS Works

Before understanding propagation, we need to review how DNS name resolution works.

The DNS Hierarchy

DNS is a distributed hierarchical system. When you type example.com in your browser, the request passes through several levels:

1. Local cache — the browser and operating system check their cache
2. Recursive resolver — the DNS server of your ISP or a public one (8.8.8.8, 1.1.1.1)
3. Root servers — point to the .com zone servers
4. TLD servers — the .com zone servers point to the domain's authoritative servers
5. Authoritative DNS — the server holding the actual domain records returns the IP address

Each level can cache the response, and it is precisely this caching that creates the delay when updating records.

Recursive Resolvers

Recursive DNS servers are key participants in the process. They perform the full name resolution cycle and cache the result. Thousands of recursive resolvers operate worldwide: ISP servers, corporate DNS servers, and public services (Google DNS, Cloudflare DNS, Yandex DNS).

Each of these servers caches DNS records independently. That's why changes propagate unevenly — one resolver may update the record within a minute, while another takes a full day.

TTL — Time to Live

TTL is the time (in seconds) that a DNS record can be stored in cache. When you create a DNS record, you specify the TTL. Recursive resolvers cache the record for the specified duration and don't query the authoritative server until the TTL expires.

Common TTL Values

How TTL Affects Propagation

If your A record's TTL is 86400 seconds (24 hours), then after changing the IP address, recursive resolvers will continue serving the old IP until the cached TTL expires. In the worst case (a resolver fetched the record one second before the change), the update will take a full 24 hours.

Why Propagation Takes Time

1. Recursive Resolver Cache

This is the main reason. Thousands of DNS servers around the world store cached copies of your records. Each server will only update after the record's TTL expires in its cache.

2. Negative Caching

If a DNS record didn't exist and someone queried it before creation, the resolver may cache a "negative" response (NXDOMAIN). The domain's SOA record contains a minimum TTL parameter that determines how long negative responses are cached.

3. Operating System Cache

The operating system also caches DNS responses. On Windows, you can flush the cache with ipconfig /flushdns, on macOS — sudo dscacheutil -flushcache, on Linux — systemd-resolve --flush-caches.

4. Browser Cache

Browsers have their own DNS cache, usually with a short TTL (1–2 minutes). In Chrome, you can clear it at chrome://net-internals/#dns.

5. Intermediate Caches

Corporate firewalls, proxy servers, and VPNs may have their own DNS caches, often with increased TTL to reduce load.

How to Speed Up DNS Propagation

Plan Ahead

The most effective strategy is to lower the TTL in advance:

1. 24–48 hours before the planned change, reduce the TTL to 300 seconds (5 minutes)
2. Wait for the old TTL to expire in all caches
3. Make the change — propagation will now take 5 minutes at most
4. After confirming everything works, restore the TTL to its normal value

Using Anycast DNS

Anycast DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS) have servers worldwide. Requests are handled by the nearest server, reducing latency and improving reliability.

DNS Notify

The DNS Notify protocol allows a master server to notify slave servers about changes. This speeds up synchronization between authoritative servers but does not affect recursive resolvers.

How to Check DNS Propagation Status

To monitor the spread of DNS changes:

• enterno.io DNS Lookup — check the current DNS records for your domain
• dnschecker.org — check DNS from multiple locations around the world
• dig — a utility for detailed DNS queries from the command line

Example of checking with dig using a specific resolver:

# Check via Google DNS
dig @8.8.8.8 example.com A

# Check via Cloudflare DNS
dig @1.1.1.1 example.com A

# Check via the authoritative server (no cache)
dig @ns1.example.com example.com A

DNS Record Types and Their Update Characteristics

A and AAAA Records

The primary records that point a domain to an IP address. Most commonly updated when changing hosting or servers. Recommended TTL for planned changes — 300 seconds.

CNAME Records

Create an alias from one domain to another. It's important to remember that a CNAME for a subdomain requires resolution of the target record, which adds an extra step (and an additional cache layer).

MX Records

Control email routing. An error when updating MX records can lead to lost emails. It's recommended to set a high TTL and change them with extra caution.

NS Records

Point to the domain's authoritative servers. Updating NS records is the most critical DNS operation. NS record propagation can take up to 48 hours because they are cached at the TLD server level.

TXT Records

Used for SPF, DKIM, DMARC, and domain verification. When updating SPF records, older servers may reject or mark your email as spam until propagation is complete.

Common Issues

• "It works for me but not for my client" — different DNS servers, different caches. Check through multiple resolvers
• Propagation taking more than 48 hours — likely not a cache issue but a configuration error. Check your records via DNS Lookup
• Different response on each request — Round Robin DNS or synchronization issues between authoritative servers
• SERVFAIL after NS change — new NS servers are not yet configured or not responding. Always configure new NS servers before changing delegation

DNS Migration Checklist

1. 48 hours in advance, lower the TTL of all records to 300 seconds
2. Make sure the new server is fully ready and operational
3. Make the DNS changes
4. Verify propagation through multiple DNS servers
5. Do not shut down the old server for at least 48 hours
6. Monitor traffic on both servers
7. After migration is complete, restore the TTL to its normal value
8. After one week, verify the old server is no longer receiving traffic