What a DNS propagation check is measuring
A DNS propagation check is a sample of cached answers, not a broadcast of your edit. You ask several recursive resolvers for one hostname and one record type, then compare what they return. The authoritative nameserver already has the value you saved.
A resolver that still shows the old value is inside its TTL. It will not ask again until that countdown ends. Two cities can disagree, and both answers are what a visitor in that city would get right then.
The check is done when the resolvers you care about return the value you published. After a new registration, start with the NS record: that is the delegation stored at domain registration in India. An A record can look empty until those nameservers are the ones resolvers are asking.
Why a DNS propagation check is not instant
The delay is a cache, not a queue. Each resolver stores the last answer and a TTL. Until that TTL hits zero, it keeps repeating the old value and does not contact your nameserver.
Caches sit on your computer, in the browser, at the ISP, and on public resolvers such as 8.8.8.8 and 1.1.1.1. A check of public resolvers can look finished while your own network is still old, or the other way around.
Nothing pushes the new record to every ISP. Each cache expires on its own clock. A map that is half updated is the normal middle of a change, not a sign that the edit failed.
How long each DNS change takes to show on a check
The timer you control is the TTL on the record. A 300-second TTL can turn over in about five minutes. An 86,400-second TTL can take a day. Nameserver changes also wait on the parent zone, which often outlasts an A record.
| Change | What must expire | A finished check shows |
|---|---|---|
| A or AAAA | That record's TTL | The same IP on every resolver you queried |
| CNAME | The alias TTL, then the target's TTL | The alias target you saved, and that target resolves |
| MX or TXT | That record's TTL | The mail host or the text string you saved |
| NS | The parent zone's TTL, often longer than an A record | The new nameserver hostnames on every resolver |
The checkers that rank for this query describe a mixed result lasting up to 48 hours. One of them also mentions waits toward 72 hours. Those numbers come from their pages, not from a timer on your record. The clock you can read is the TTL you set, plus the parent TTL when you change nameservers.
A mixed NS check a few minutes after a delegation change is normal. Resolvers are still repeating the parent zone's previous nameserver set, including for a .IN name. That cache sits at the registry, not in the zone you just edited.
How to run a DNS propagation check
Run the check on the hostname and the record type you changed. Strip https:// and any path. example.com and www.example.com are different names, and a checker will not guess which one you edited.
- Write down the new value first: the IPv4 or IPv6 address, the nameserver hostnames, or the MX or TXT string.
- Enter the hostname and select A, AAAA, CNAME, MX, TXT, or NS. If the checker lets you paste an expected value, paste the new one so a tick means a match.
- Include a location in India when the list has one, such as Mumbai, and one distant city.
- Treat identical answers as done for the resolvers you queried. Treat a split as TTL still running, and check again after that TTL rather than every minute.
You can do the same comparison without a website. Run nslookup example.com 8.8.8.8 and nslookup example.com 1.1.1.1. For nameservers, use nslookup -type=NS example.com 8.8.8.8. If the two resolvers disagree, the check is still in progress. If both disagree with the zone you saved, the edit did not land.
If the tool has a CD flag, run one pass with it and one without. The flagged pass asks the resolver to skip its own cache. The normal pass is what a visitor still receives. Record types in the dropdown are covered in DNS records explained.
How to flush a local DNS cache before the next check
Your own device can hide a result the public check already updated. Flush the local cache, then look again. Flushing does not clear an ISP resolver.
On Windows, open Command Prompt and run ipconfig /flushdns. The reply should say the DNS Resolver Cache was flushed. On a Mac, open Terminal and run sudo dscacheutil -flushcache, then sudo killall -HUP mDNSResponder. The second command restarts the local resolver and often prints nothing.
Android has no single flush command. Turn private DNS off for the test if you enabled it, toggle airplane mode, and recheck. In Chrome on any device, open chrome://net-internals/#dns and clear the host cache. That clears the browser only.
How to lower TTL before the next DNS change
Shorten the next change by lowering TTL before you edit the target. If the record is 86,400 seconds today, set it to 300, then wait a full day so caches store 300 instead of a day. Only then change the address or the nameservers.
After the check is clean, raise the TTL again so resolvers are not querying your nameservers on every page view. Change the TTL on the record in the DNS panel. A hosts-file edit on your laptop does not change what the check shows for anyone else.
When a DNS propagation check shows a real fault
A split result is a cache. These results are a fault, and waiting will not fix them.
- Old everywhere — every resolver, including a query straight to your nameserver, returns the old value. The edit was not saved, or the domain still uses another zone.
- www left behind — the bare domain is new and www is old. Update both, or point www at the apex with a CNAME, then check each name.
- NXDOMAIN — every resolver says the name does not exist. It is missing from the zone, or the parent still delegates to servers that do not have it.
- SERVFAIL — several resolvers fail the query while others answer. Those servers are down or refusing. A TTL countdown will not repair an outage.
- Only your browser — the public check is clean after a flush, and a private window shows the new site. The DNS change is already live for everyone else.
If the NS hostnames in the check do not match the ones you set at the registrar, confirm the delegation with a Whois lookup before you edit the zone again. Editing the old nameserver's zone will not move a resolver that is still delegated elsewhere.
Frequently Asked Questions
How do I run a DNS propagation check?
Enter the hostname without https://, choose the record type you changed, and compare answers from several public resolvers, including a city in India if the list has one. A split between old and new values means those caches are still inside the TTL.
How long does DNS propagation take?
It lasts as long as the TTL on the cached copy. A 300-second TTL is about five minutes, and an 86,400-second TTL can take a day. A nameserver change also waits on the parent zone, and checkers often show a mix for up to 48 hours.
Which DNS record should the check use?
Use the type you edited. An A-record check does not show a new MX or TXT value. The bare domain and www are different names, so check the hostname the browser requests.
Why do I see the old site when the check is clean?
Public resolvers can be new while your computer or browser still holds the old address. Flush the operating-system DNS cache, clear the browser host cache, and reload. If one city on the check is still old, that resolver has not reached the end of the TTL.
How do I flush DNS on Windows, Mac and Android?
On Windows, open Command Prompt and run ipconfig /flushdns. On a Mac, run sudo dscacheutil -flushcache and then sudo killall -HUP mDNSResponder. Android has no matching command: turn private DNS off for the test, toggle airplane mode, and check again.
Can I speed up DNS propagation?
Only for the next edit. Set the TTL to 300 seconds, wait out the previous TTL so caches learn the short value, then change the record. You cannot force an ISP that already stored a long TTL to drop it.
Is WebJi® an Indian company?
Yes. WebJi® has its registered office in Jaipur, Rajasthan, and has been in this business since 2005. Clients are served online. Email support@webji.services is 24/7 in Hindi and English, with an average first reply under 60 minutes.