DNS Propagation Times, TTLs, and Nameserver Changes

Quick Summary – DNS Propagation

DNS propagation is mostly the process of cached answers expiring. The authoritative server may have the new record immediately, while different resolvers continue returning the old answer for different lengths of time.

Typical timing — An ordinary record may appear across networks within minutes or its current TTL, but there is no universal exact deadline.
TTL matters — A resolver can keep an old answer until its cached TTL expires, and lowering TTL later cannot shorten an existing cache.
Nameserver changes — Changing NS records can take longer because parent-zone delegation and old resolver caches are involved.
Check layers — Compare the authoritative server, public recursive resolvers, local DNS, and HTTP response separately.
Check IPv6 — An old AAAA record can send IPv6 clients to a different server even when the A record is correct.
Watch exceptions — NXDOMAIN, DNSSEC failures, and CDN caching can resemble propagation delays but require separate checks.

DNS propagation usually means cached answers expiring, not a new record being pushed across the internet. An ordinary change may appear within minutes or its TTL, while nameserver changes, DNSSEC errors, negative caching, and an overlooked AAAA record can make the delay look like a broken migration.

Table of Contents · 13 min read

DNS propagation is mostly a cache-expiry problem
How long should DNS propagation take?
TTL only helps if you lower it early enough
The record changed, so why is the old site still loading?
Why nameserver changes usually take longer
Query the layers yourself
DNSSEC and negative caching change the diagnosis
A migration routine I can trust
Check These Before Calling It DNS Propagation
Frequently Asked Questions
Sources

DNS propagation is mostly a cache-expiry problem

I have watched a DNS panel show the new address while my own browser continued opening the old server. The panel was not necessarily wrong, and the browser was not necessarily broken. Usually, different recursive resolvers simply had different cached answers.

When you change an IP address, record type, or nameserver delegation, there is no central switch that updates every resolver at once. The authoritative server may return the new answer immediately, while ISP resolvers, operating systems, browsers, and company networks continue using the old answer until its cache lifetime ends.

🚀 Boost Your Speed with VPS Server!

Speed up your projects with high-performance SSD storage and 99.9% uptime guarantee.

Get VPS Hosting

That is what people usually mean by DNS propagation. A new record is not being pushed across the internet. Recursive resolvers are expiring old answers and asking the authoritative server again.

Authoritative server versus recursive resolver

An authoritative DNS server holds the records for a domain. A recursive resolver looks up those records on behalf of your computer, VPS, or application. Your ISP’s resolver, Google Public DNS, and Cloudflare Resolver are all examples of recursive resolvers.

If an A record has a TTL of 3,600 seconds, a resolver can normally keep that answer for up to one hour. It does not need to ask the authoritative server again before the cached answer expires. That is why a DNS panel can show the new record while some visitors still reach the old IP.

☁️ Gain Flexibility with Cloud Server!

Experience the power of cloud with scalable resources and instant backups.

Cloud Server Plans

Start here – Before changing anything, check the TTL, confirm the authoritative nameservers, and query the authoritative server directly.

How long should DNS propagation take?

For a normal A, AAAA, or CNAME change, different networks may see the update within minutes or sometime before the record’s TTL expires. There is no exact moment when every user must see the new answer.

A TTL of 300 seconds does not mean that everyone switches exactly five minutes after your edit. A resolver that queried just before the change may keep the old response for nearly five minutes. Another resolver may query after the change and see the new response immediately.

Change	Typical planning range	What affects it
A record with TTL 300	Minutes	The resolver’s cache age and any local caching.
A record with TTL 3600	Up to about one hour	The old answer may remain valid until its cached TTL expires.
Nameserver change	Several hours or longer	Parent-zone delegation and resolver caches are involved.
NXDOMAIN response	Negative TTL from the SOA record	A missing record can be cached just like a positive answer.

Nameserver changes need more care than ordinary record edits. The delegation in the parent zone changes, and some resolvers may still use the old nameservers. Lowering the TTL now also cannot shorten an answer that was already cached with a higher TTL.

For an ordinary record, plan around its current TTL. For a nameserver migration, allow several hours and keep watching the delegation. If old answers still appear consistently after 48 hours, inspect the delegation, DNSSEC, and resolver behavior instead of waiting blindly.

Keep in mind – TTL is an approximate cache lifetime, not a promise that every visitor changes at the same time.

TTL only helps if you lower it early enough

TTL tells a resolver, in seconds, how long a DNS answer may be cached. A value of 300 means five minutes; 86,400 means 24 hours. The TTL field is part of the DNS resource-record format described in RFC 1035.

Before a planned server move, I usually lower important records to 300 or 600 seconds. That lower value must reach recursive resolvers before the migration. If I reduce the TTL immediately before changing the address, some resolvers may still hold the previous answer with its higher TTL.

dig +noall +answer example.com A

dig @1.1.1.1 +noall +answer example.com A
dig @8.8.8.8 +noall +answer example.com A

The first command uses your configured resolver. The next two query Cloudflare and Google Public DNS directly. The number beside the record is the remaining TTL. Run a command twice and watch whether that number counts down; that gives you a useful view of the resolver’s cache age.

A low TTL is not automatically the right answer. It can create more queries for your authoritative DNS service and reduce cache efficiency. For a site that rarely changes, 3,600 seconds or more may be perfectly reasonable. Lower it for a planned migration, then raise it again after the move is stable.

I have forgotten this timing before and lowered a TTL only a few minutes before a change. The DNS panel accepted the edit, but it could not retroactively clear caches around the internet. DNS is patient in a very literal way.

Caution

Lowering TTL immediately before a migration does not erase answers already cached with the previous, higher TTL.

The record changed, so why is the old site still loading?

An old page does not identify the failing layer by itself. I separate DNS from HTTP before touching the configuration.

Local cache: Your operating system or browser may still have the earlier answer.
Recursive resolver: Your provider’s resolver may return the old IP until its TTL expires.
Authoritative DNS: You may have edited the wrong zone or a nameserver that is not authoritative for the domain.
Application layer: You may already be reaching the new IP, but a redirect, CDN cache, or web server is serving old content.
Hosts file: On Linux, /etc/hosts can override DNS. On Windows, check C:\Windows\System32\drivers\etc\hosts.

Refreshing a browser is not a reliable test. First find the IP returned by DNS, then check what HTTP response that IP serves. I use the same separation when diagnosing the How to Fix DNS_PROBE_FINISHED_NXDOMAIN Error.

dig +short NS example.com
dig +short A example.com
curl -I --resolve example.com:443:203.0.113.20 https://example.com/

dig +short NS lists the delegation returned by your resolver, while dig +short A shows the address it returns. The --resolve option makes curl connect to the specified IP while still sending the requested hostname and SNI. That makes it useful for testing the HTTPS service without changing DNS.

Do this first – Test NS, A or AAAA, and HTTP separately. A browser result alone cannot tell you which layer is wrong.

Example

A domain can have a correct A record and an old AAAA record at the same time. IPv4 and IPv6 clients may then reach different servers.

Why nameserver changes usually take longer

Changing an A record edits one record inside the existing authoritative zone. Changing nameservers changes the delegation in the parent zone, which tells resolvers where the zone should be queried.

During the transition, both DNS providers should serve the same records. A resolver with the old delegation may query the old provider, while another resolver with the new delegation queries the new one. Do not shut down the old zone immediately.

Compare A, AAAA, MX, TXT, CAA, and CNAME records on both providers. The website is only one part of the migration. MX records affect mail, TXT records may be used for SPF, DKIM, or verification, and CAA records can affect certificate issuance.

Export the zone before making the change. I once treated an NS migration as a website-only task and nearly missed a verification TXT record. The page opened, which was not enough.

The staged approach in Cloud Migration Checklist: A Step-by-Step Planning Guide works well here too: prepare the new service, test it, then change the delegation during a planned window.

Query the layers yourself

Online DNS checkers can be useful, but they may have their own caches and resolver pools. When I need an answer I can trust, I query several resolvers directly from a shell.

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer

dig +trace example.com A

The first three commands compare recursive resolvers. The +trace query follows the delegation chain from the root servers. It does not show your local resolver’s cache, but it helps reveal whether the delegation reaches the expected authoritative servers.

Query an authoritative server directly as well:

dig +short NS example.com
dig @ns1.example-dns.com example.com A +noall +answer

If the authoritative server returns the new IP while public resolvers return the old one, ordinary caching is the likely explanation. If the authoritative server also returns the old IP, check whether you edited the wrong zone, saved the record, or identified the correct DNS provider.

Check IPv6 every time. An A record can point to the new server while an AAAA record still points to the old one. IPv6 clients then take a different path, and the result looks like propagation trouble even though both records are following their configuration.

Compare both families – Query A and AAAA through at least two public resolvers and directly through an authoritative nameserver.

Tip

Query the authoritative nameserver directly before blaming propagation. If it still returns the old record, a recursive resolver cache is not the main problem.

DNSSEC and negative caching change the diagnosis

DNSSEC adds signatures and a chain of trust to DNS answers. During a nameserver migration, an outdated DS record at the parent combined with an incompatible DNSSEC configuration can make validating resolvers reject the response with SERVFAIL. That is not an ordinary TTL delay.

Missing records can be cached too. RFC 2308 describes negative caching and the SOA values used to determine how long a resolver may remember an NXDOMAIN or other negative response. If a subdomain did not exist when someone queried it, creating it a minute later may not make it visible everywhere immediately.

dig example.com SOA +noall +answer
dig example.com DNSKEY +dnssec +noall +answer
dig example.com A +dnssec +noall +answer

The SOA serial helps confirm that you are looking at the expected zone version. Its fields also provide information used for negative caching. A DNSSEC query may include RRSIG records. When the result is SERVFAIL, inspect the DNSSEC chain instead of assuming the resolver is merely slow.

A CDN adds another cache layer. DNS may already point to the new service while the CDN continues serving an older HTTP response according to Cache-Control or its own policy. That is separate from the DNS caching described in What Is a CDN? How It Speeds Up Websites.

Separate the errors – For NXDOMAIN, inspect negative caching. For SERVFAIL, check DNSSEC and delegation before changing records again.

A migration routine I can trust

Before changing DNS

Export the current A, AAAA, CNAME, MX, TXT, CAA, and NS records.
Verify the authoritative nameservers with dig +short NS yourdomain.tld.
Test the new web, mail, TLS, and application services by direct IP or temporary hostname.
Lower critical TTLs early enough for recursive resolvers to receive the lower value.

After changing DNS

Query the new answer directly from an authoritative nameserver.
Compare 1.1.1.1, 8.8.8.8, and your local resolver.
Confirm that A and AAAA follow the same migration plan.
Test mail delivery, verification TXT records, TLS, redirects, and CDN behavior separately.

The virtual-host and TLS checks in How to Install and Configure Nginx on Ubuntu are useful before changing DNS. DNS can point to the correct IP while Nginx still selects the wrong site because of an incorrect server_name.

Keep the old DNS provider, mail records, and monitoring checks active for at least one full TTL cycle after the change. For an NS migration, I keep them longer when practical.

That habit came from my homelab. I changed an A record, checked IPv4, and declared the move finished. The AAAA record still pointed to the old machine, so IPv6 clients quietly went somewhere else. Since then, A and AAAA sit beside each other on every migration checklist.

From the field

I once checked only IPv4 after a homelab DNS change and missed an unchanged AAAA record. IPv6 clients kept reaching the old machine, so both address families are now on my migration checklist.

Check These Before Calling It DNS Propagation

Export all current DNS records before changing the zone.
Verify the authoritative nameservers with dig.
Lower important TTLs before the migration, not at the last minute.
Test the new server directly by IP or temporary hostname.
Query the authoritative server and at least two public resolvers.
Check both A and AAAA records after the change.
Keep the old DNS service and monitoring active for one full TTL cycle.

During your next DNS migration, start with the authoritative answer rather than the browser. A few direct dig queries usually show whether you are waiting for cache expiry or debugging the wrong layer.

Explore VPS plans

When I troubleshoot DNS propagation, I also make sure I understand what is actually being resolved, so I recommend reading our guide, Domain vs URL: What Is the Difference?, for a clear explanation of domains, hosts, and complete URLs.

Frequently Asked Questions

How long does DNS propagation take for an A record?

Most A record changes appear on different networks within a few minutes to the record's TTL. A 300-second TTL allows a resolver to cache the answer for about five minutes, but the timing depends on when that resolver last queried the record. Local DNS, browser caches, and hosts files can add another layer.

Does lowering TTL make DNS propagation instant?

No. Lowering TTL helps only after resolvers have seen and cached the lower value. A resolver that already stored the old answer with a higher TTL can keep using it until that original cache lifetime ends. Lower the TTL before a planned change, then restore it after the migration is stable.

Why does my DNS panel show the new IP while visitors see the old site?

The panel may show the authoritative zone while visitors use recursive resolvers that still have the old answer cached. You may also have edited the wrong nameserver, left an AAAA record pointing to the old host, or reached the new IP where an HTTP configuration or CDN still serves old content. Compare DNS and HTTP separately.

Why do nameserver changes take longer than A record changes?

An A record change affects a record inside the existing authoritative zone. A nameserver change affects the delegation stored in the parent zone, so resolvers can temporarily use either the old or new provider. Keep both providers serving matching records until the transition settles, and plan for several hours rather than one short TTL.

Can DNS propagation cause an NXDOMAIN error?

Yes. Resolvers can cache a negative answer when a record does not exist. RFC 2308 describes how SOA values provide information for negative caching. If you create a record shortly after someone queried its nonexistent state, some resolvers may continue returning NXDOMAIN until that negative cache lifetime expires.

How can I tell whether DNS or my web server is the problem?

Query the authoritative nameserver and several recursive resolvers with dig, then test the destination directly with curl –resolve. If the authoritative server returns the new IP but public resolvers return the old one, caching is likely. If the correct IP answers but the wrong website appears, inspect the virtual host, TLS configuration, redirects, and CDN cache.