DNS troubleshooting
You changed the DNS record. Your website still shows the old destination. Do not change the record again yet.
DNS changes are often delayed by caching, not by a failed configuration. The safest approach is to check the authoritative answer first, then compare recursive resolvers, and only then troubleshoot the browser, device or hosting layer.
Quick answer
DNS propagation is not one global timer. Recursive resolvers cache DNS answers according to their time to live, or TTL. A resolver with an expired or empty cache can see your new record quickly, while another resolver may continue serving an older cached answer until its remaining TTL expires. Nameserver changes and negative DNS answers can involve additional caches, so verify each layer before editing DNS again.
TTL conversion examples
What DNS propagation actually means
The phrase DNS propagation makes it sound as though a new record is pushed to every DNS server on the internet. That is not how normal DNS resolution works. Your authoritative DNS provider holds the current record, while recursive resolvers used by ISPs, companies and public DNS services may keep previously received answers in cache.
The DNS specification defines TTL as the time limit for how long a resource record can be kept in cache. RFC 1034 also explains that reducing TTL before an anticipated change can reduce the period of inconsistency after the change. This is why the TTL that was in effect before your cutover can matter more than the TTL you see after the cutover.
How one DNS answer reaches a visitor
- 1You publish the record
The authoritative DNS zone is updated with the new A, AAAA, CNAME, MX, TXT or other record.
- 2A resolver asks for the answer
A recursive resolver checks its cache. If the answer is missing or expired, it queries the authoritative DNS chain.
- 3The resolver caches the response
The returned record can be reused until its TTL expires, reducing repeated DNS lookups.
- 4The visitor receives an answer
Two visitors can temporarily receive different answers if their resolvers cached the record at different times.
TTL value compared with nominal cache window
Report analysis
Why TTL is not a countdown shared by everyone
Suppose an A record had a 3,600-second TTL. Resolver A cached the old answer five minutes before you changed the record. Resolver B had no cached answer at the time of the change. Resolver B can request the new authoritative answer immediately, while Resolver A may still have about 55 minutes remaining on its old cached answer. This is a worked example, not observed traffic.
- A correct DNS change can appear at different times to different users.
- Lowering TTL after the change does not retroactively shorten an answer that a resolver already cached under the old TTL.
- The authoritative answer is the first thing to verify when you are unsure whether a change actually saved.
How long do DNS changes take?
There is no protocol-wide rule that every DNS change takes 24 or 48 hours. The practical delay depends on which record changed, the TTL that resolvers previously cached, whether delegation or nameservers changed, whether a negative answer was cached, and whether your device or application has another cache in front of DNS.
Cloudflare documents that its proxied records use an Auto TTL of 300 seconds, or five minutes, while also warning that local DNS caching can make a user experience the old answer for longer. Its DNS-only records can use configurable TTL values. See Cloudflare's TTL documentation for the provider-specific behavior.
| Change | What may be cached | First verification | Common mistake |
|---|---|---|---|
| A / AAAA / CNAME | The previous resource record answer | Query the authoritative nameserver for the exact hostname and record type | Changing the record repeatedly because one resolver still shows the old value |
| MX / TXT | The previous mail or verification record | Check the authoritative zone, then test multiple recursive resolvers | Assuming an email problem is DNS propagation without checking the live MX/TXT answer |
| Nameservers / delegation | Delegation and nameserver information | Confirm the registrar delegation and the new authoritative nameservers | Flushing a subdomain while a resolver is still using stale delegation |
| New hostname after NXDOMAIN | A cached negative answer | Check authoritative DNS and the zone SOA negative-cache behavior | Expecting every resolver to forget an earlier NXDOMAIN immediately |
Do not use 24 to 48 hours as a reason to avoid diagnosis
Waiting can be correct when the authoritative record is new and a resolver is still serving a cached answer. Waiting is not useful when the authoritative zone itself is wrong. Verify the source of truth before deciding that time is the solution.
Check DNS propagation in the right order
- Record the expected valueWrite down the hostname, record type and exact new value you expect. For an A record, that is the intended IPv4 address. For MX, it is the mail destination and priority. This prevents you from comparing the wrong record.
- Query the authoritative DNSAsk the authoritative nameserver directly. If it still returns the old value, the problem is not propagation. Fix the zone, confirm you edited the correct DNS provider, and check whether the domain is delegated to those nameservers.
- Compare more than one recursive resolverOnce authoritative DNS is correct, compare public or ISP resolvers. Different answers can be normal while cached TTLs expire.
- Inspect the TTL that comes backA resolver answer with a remaining TTL shows how long that cached copy may continue to be reused. The number normally counts down while the answer remains in cache.
- Only then check local caches and the applicationIf public resolvers return the new answer but your device does not, investigate the operating system, browser, router, VPN, corporate DNS, CDN or application layer instead of changing the authoritative record again.
# Ask a public resolver for an A record
dig @8.8.8.8 example.com A
# Query a specific authoritative nameserver
dig @ns1.example-dns.com example.com A
# Follow the delegation path
dig +trace example.comWhat your DNS test result means
- IfThe authoritative nameserver still returns the old value→Then
Correct the authoritative zone or confirm that you are editing the DNS provider actually delegated by the registrar.
- IfAuthoritative DNS is new but one recursive resolver is old→Then
Treat it as a cache-expiry case. Check the remaining TTL and avoid making another DNS change just to chase one resolver.
- IfSome resolvers are new and others are old→Then
Compare TTLs and delegation. This is consistent with independent caches expiring at different times.
- IfEvery public resolver is new but your browser is old→Then
Check local DNS cache, router, VPN, proxy, browser, CDN or application caching.
- IfThe hostname was recently missing and still returns NXDOMAIN somewhere→Then
Consider negative caching. A resolver can cache the fact that a name did not exist until the negative-cache TTL expires.
Why NXDOMAIN can remain after you create the missing record
Positive DNS answers are not the only responses that can be cached. DNS resolvers can also cache negative answers such as NXDOMAIN, which means the requested domain name did not exist at the time of the lookup. RFC 2308 defines negative caching and explains how the zone's SOA information provides the lifetime for a cached negative answer.
This matters when you query a hostname before creating it. A resolver may learn that the hostname does not exist and cache that result. When you create the record a few minutes later, the authoritative server may already have the correct new answer while that resolver continues returning the cached negative response until it expires.
A cache flush is local to the resolver you flush
Google Public DNS provides a cache flush tool and advises flushing the main domain before subdomains when DNS hosting or registrar delegation recently changed. That can refresh Google's cache, but it does not force every ISP, company resolver or device on the internet to discard its own cache. See Google Public DNS Flush Cache.
Nameserver changes need a slightly different check
When you change nameservers, you are changing delegation rather than only changing a record inside one DNS zone. A recursive resolver can have delegation information about which nameservers are authoritative, then separately cache answers obtained from those servers. This is why a nameserver migration should be tested at the registrar/delegation layer and at the record layer.
Nameserver migration verification path
- 1Registrar delegation
Confirm the parent zone points your domain to the intended new nameservers.
- 2Authoritative response
Query each new nameserver directly and make sure it serves the expected zone data.
- 3Recursive resolver view
Check whether public resolvers have refreshed the delegation and are now asking the new authoritative servers.
- 4Website and email checks
Verify the website plus MX, SPF, DKIM, DMARC and other records that may have been copied during the DNS-host migration.
A safer DNS-change checklist
Before and after a DNS cutover
- Export or screenshot the current DNS zone before editing anything.
- Confirm which nameservers are authoritative before you edit records.
- If the change is planned, lower the relevant TTL in advance rather than after the cutover.
- Keep the old hosting or service destination available during the transition when practical.
- Change one DNS variable at a time so you can identify the cause of a failure.
- Verify website records and business-email records separately.
- Check the new value at the authoritative nameserver before testing public resolvers.
- Record the previous value so you have a clear rollback path.
- Do not delete a correct record merely because one resolver still shows the old answer.
Pros
- Shorter TTLs can reduce how long resolvers are allowed to reuse an old cached answer after a planned change.
- They can make a rollback or second planned change become visible more quickly once resolvers refresh.
Cons
- Lower TTLs increase the frequency of DNS queries to authoritative infrastructure.
- Changing the TTL at the same moment as the record does not rewrite the TTL of copies that resolvers already cached earlier.
Practical verdict
Treat DNS propagation as a cache diagnosis, not a waiting ritual
First prove that authoritative DNS has the correct record. Then compare recursive resolvers and their TTLs. If the public DNS layer is correct, move your troubleshooting to the local, network, CDN or application layer. This sequence prevents repeated DNS edits from turning a temporary cache difference into a real outage.
Frequently asked questions
Frequently asked questions
Is DNS propagation always 24 to 48 hours?
No. DNS has no universal 24-to-48-hour propagation timer. Visibility depends on TTLs, when resolvers cached the previous answer, delegation caches, negative caching and local layers. Some users can see a new answer quickly while another resolver continues serving an older cached value until its TTL expires.
Can I force DNS propagation everywhere?
No single action can force every independent recursive resolver and device to discard its cache. Some public DNS providers offer cache-flush tools for their own resolvers, and you can clear caches you control, but you cannot centrally flush the entire internet.
Why does my website work on mobile data but not Wi-Fi after a DNS change?
The two connections may use different recursive resolvers or local caches. If authoritative DNS and major public resolvers show the new value, compare the resolver used by Wi-Fi, then check the router, VPN or device cache before changing DNS again.
Does lowering TTL after I change a record make the old cache disappear faster?
Not necessarily. A resolver that already cached the old answer did so using the TTL it received at that time. A lower TTL published later affects future responses, not the remaining lifetime of that already cached copy.
Why can NXDOMAIN continue after I create a DNS record?
Negative DNS answers can be cached. If a resolver previously learned that the hostname did not exist, it can continue returning that cached negative answer until the negative-cache TTL expires, even though the authoritative server now has the new record.
Related guides
How To Change Domain Name on WordPress (Everything You Need to Know)
Planning a domain change? Use a controlled WordPress migration process instead of treating DNS as the only moving part.
How To Fix VPN Connection Failed Due to Unsuccessful Domain Name Resolution
Use the DNS-resolution checks in this guide when a VPN cannot resolve the destination it needs.
Namecheap vs HostGator (Which One Is Right for Your Website)
Compare two hosting options before changing infrastructure and DNS together.
Sources and references
Need a safer next step?
Check the DNS layer before changing another website setting.
Use Bloggingfy's domain and troubleshooting resources to identify whether the problem is DNS, hosting, migration or a local cache before you make another production change.
