--- title: Has my DNS change propagated? How to check with the DNS Propagation Checker description: You changed a record, it works on your laptop, and someone else still lands on the old server. To check DNS propagation, ask the same question from many places at once and compare the answers with what your DNS host serves. Here's how to do it in seconds with the free DNS Propagation Checker, how to read a result that shows different answers in different places, and the dig commands that confirm it. canonical: https://watchfor.io/blog/how-to-check-dns-propagation --- # Has my DNS change propagated? How to check with the DNS Propagation Checker 2026-10-04 · WatchFor Team · Guides · guides, dns, networking You changed a record, it works on your laptop, and someone else still lands on the old server. To check DNS propagation, ask the same question from many places at once and compare the answers with what your DNS host serves. Here's how to do it in seconds with the free DNS Propagation Checker, how to read a result that shows different answers in different places, and the dig commands that confirm it. To check DNS propagation, query the same record from many locations at once and compare every answer with the value your DNS host now serves. If every location returns the new value, the change is live, and anyone still seeing the old one has it cached on their own machine or network. If some locations return the old value, their resolvers hold a cached copy that expires on its own, at the latest when the old record's TTL runs out. The free [DNS Propagation Checker](/dns-propagation-checker) does exactly that: one query, sent from 20 WatchFor locations in 7 regions at the same moment, every answer listed and pinned on a map. No signup. ## What this tool answers *What does the world resolve for this name right now?* Reach for it after changing an A, AAAA, CNAME, MX, TXT or NS record, after moving nameservers (to Cloudflare, Route 53, a new registrar), or when one customer swears your site points somewhere else. A `dig` on your laptop only shows what *your* resolver has cached; twenty answers from twenty networks show whether a problem is everywhere, in one region, or on one person's machine. ## A real example ### Checking DNS propagation when two people see different IPs A common report after a DNS change: one teammate resolves the site to one address, a colleague abroad gets another, and each is sure the other is looking at a stale record. We reproduced it with a public site that hands out different addresses on purpose. In the [DNS Propagation Checker](/dns-propagation-checker) we typed `wikipedia.org`, kept record type **A** and resolver **Auto** (each location asks its own local resolver, as a visitor there would) and pressed **Check**: ![The DNS Propagation Checker after querying the A record of wikipedia.org with each location's own resolver: 20 of 20 locations responded in 843 ms, Cape Town returned 185.15.58.224, Jakarta, Mumbai, Singapore and Tokyo returned 103.102.166.224, and every marker on the world map is green](/blog/how-to-check-dns-propagation-map.webp) All 20 locations answered within 843 ms, each with `NOERROR` and one address. But there were **seven different addresses**: | Address | Returned to | Reverse name | | --- | --- | --- | | 185.15.59.224 | Frankfurt, London, Stockholm, Vilnius, Tel Aviv | text-lb.esams.wikimedia.org | | 103.102.166.224 | Jakarta, Mumbai, Singapore, Tokyo, Sydney | text-lb.eqsin.wikimedia.org | | 185.15.58.224 | Cape Town, Madrid, Paris | text-lb.drmrs.wikimedia.org | | 208.80.154.224 | Montreal, N. Virginia, Ohio | text-lb.eqiad.wikimedia.org | | 198.35.26.224 | Oregon, Auckland | text-lb.ulsfo.wikimedia.org | | 208.80.153.224 | Querétaro | text-lb.codfw.wikimedia.org | | 195.200.68.224 | São Paulo | text-lb.magru.wikimedia.org | Is that a propagation problem? No. The reverse names say what each address is: the load balancer of one Wikimedia data centre (esams is Amsterdam, eqsin Singapore, eqiad Ashburn, and so on). Wikipedia's nameservers send each visitor to the nearest data centre. That's **GeoDNS**, and seven answers is the correct result; the command-line section shows how we confirmed it at the source. **The answer:** both teammates were right and nothing was stale. For your own domain, read it the other way round: unless your DNS host does geographic routing, the correct result is *one* answer everywhere, and a location still showing the old value is a cache that hasn't expired yet. ## How to read the results | What you see | What it means | | --- | --- | | **20 / 20 responded · 843ms total** | How many locations got a reply, and how long the run took. Fewer than 20 means timeouts or unreachable resolvers, not a missing record. | | **Location and flag** | Where the query was sent from. Rows are grouped by region, so a continent that disagrees stands out. | | **via prober's local resolver** | Who answered. **Auto** uses the resolver at that location; a preset (Cloudflare, Google, Quad9…) or **Random** names the public resolver that was asked. | | **Value under the location** | The record set it received: addresses for A/AAAA, `priority host` for MX, the text for TXT, hostnames for NS and CNAME. | | **Time in ms** | How long that location waited. A cached answer takes a few milliseconds (Singapore: 4 ms); a slow one often means the resolver had to ask the authoritative servers. It says nothing about whether the value is right. | | **Green check** | Answered with at least one record. Green means "answered", not "matches what you expect"; comparing the value is your job. | | **Amber** | Answered without records: `NXDOMAIN` (no such name), an error code such as `SERVFAIL` or `REFUSED`, or `NOERROR` with an empty answer (the name exists, that record type doesn't). | | **Red** | The probe itself failed at that location, so there's no DNS answer to read. | | **Grey** | No reply within 6 seconds, or the resolver was unreachable from there. | | **World map** | The same results as dots; hovering a row highlights its dot. **Download** saves the map, alone or with the results, as SVG or PNG; **Share** (signed in) makes a link to this exact result. | It checks A, AAAA, CNAME, MX, TXT and NS. For SOA, CAA, SRV or reverse (PTR) lookups, use the [DNS checker](/dns-checker), which asks one resolver at a time but supports every type. ## More ways to use it - **Before a migration.** Run it on the record you're about to change and note what every location sees, so afterwards you know which answers are new. - **After moving nameservers.** Check **NS**. Until every location returns the new provider's nameservers, some resolvers still ask the old provider, and edits at the new one won't reach them. - **When mail goes missing after a switch.** Check **MX** and the SPF **TXT** record. A location still returning the old mail host explains mail trickling into the old server. - **Pointing a subdomain at a vendor.** Confirm every region returns the vendor's **CNAME** target before asking them to issue the certificate. - **Testing one resolver, or your own server.** Pick Cloudflare `1.1.1.1` or Google `8.8.8.8` to see what that service answers in each region, or **Custom IP** to query your authoritative server from 20 places. ## Tips and gotchas - **Nothing actually propagates.** Your DNS host serves the new value the moment you save; what lags is caches. Each resolver keeps the old answer until its TTL expires, so the TTL that matters is the one the record had *before* the change. Lower it a day ahead; the [TTL playbook](/blog/dns-propagation-myths) has the timing. - **"Up to 48 hours" is about nameservers.** The `.com` registry publishes delegations with a TTL of 172,800 seconds, which is 48 hours. An A record with a 300-second TTL is refreshed everywhere within five minutes. - **A brand-new record can be slow to appear.** If anyone asked for the name before it existed, resolvers cache the "doesn't exist" answer for the negative TTL in your zone's SOA record (RFC 2308). - **Different answers aren't always a problem.** CDNs, GeoDNS and load balancers answer differently by region, as above. Compare with what your provider is configured to serve, not with the majority. - **All green here, still wrong for one person?** Their device has it cached: `ipconfig /flushdns` on Windows, `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` on macOS, `resolvectl flush-caches` with systemd-resolved. Public resolvers can be purged per name at [Google Public DNS](https://developers.google.com/speed/public-dns/cache) and [Cloudflare 1.1.1.1](https://one.one.one.one/purge-cache/). - **It checks resolvers, not your website.** The new IP everywhere proves DNS, not that the server behind it answers; that's the [HTTP header checker](/http-header-checker) or [port checker](/port-checker). ## Check it from the command line too `dig` asks one resolver at a time, and the TTL in each answer is how long that cache keeps its copy: ```bash dig +noall +answer @1.1.1.1 wikipedia.org A dig +noall +answer @8.8.8.8 wikipedia.org A ``` ```text wikipedia.org. 51 IN A 185.15.59.224 wikipedia.org. 10 IN A 185.15.59.224 ``` 51 and 10 are seconds left on those cached copies. The authoritative nameserver has no cache in front of it, so its TTL is the full value, the longest anyone can keep an old answer after a change: ```bash dig +short NS wikipedia.org dig +noall +answer @ns0.wikimedia.org wikipedia.org A ``` ```text wikipedia.org. 180 IN A 185.15.59.224 ``` To watch GeoDNS decide at the source, pass a client subnet (EDNS Client Subnet), which Wikimedia's nameservers use to pick a data centre: ```bash dig +noall +answer +subnet=8.8.8.0/24 @ns0.wikimedia.org wikipedia.org A dig +noall +answer +subnet=200.160.0.0/24 @ns0.wikimedia.org wikipedia.org A ``` ```text wikipedia.org. 180 IN A 208.80.154.224 wikipedia.org. 180 IN A 195.200.68.224 ``` A US subnet got Ashburn, a Brazilian one São Paulo: the same split the checker saw. `dig +short -x 195.200.68.224` returns `text-lb.magru.wikimedia.org.`, which is how the table above was labelled. For your own domain: if `dig @` returns the new value, the change is done at the source, and everything else is caches counting down. ## Keep watching it A propagation check is a snapshot. For records that matter (your apex A record, your MX, the CNAME your CDN depends on), a [DNS monitor](/dns-monitoring) re-checks from several locations on a schedule and, with the **Expected DNS Records** rule, opens an incident when the answer stops matching the values you set: a change nobody planned, an expired domain parked elsewhere, a hijacked record. The [DNS hijacking guide](/blog/detect-dns-hijacking) walks through the setup. ## FAQ **How long does DNS propagation take?** As long as the old record's TTL: about five minutes for a 300-second TTL, up to a day for 86,400 seconds. Nameserver changes for `.com` domains can take up to 48 hours because of the registry's own TTL. **Why do I still see the old IP when the checker shows the new one?** Your computer, browser or network resolver still has the old answer cached. Flush the local cache or wait out the old TTL; querying `1.1.1.1` directly tells you whether your office or ISP resolver is the one holding it. **Can I speed up DNS propagation?** Not after the change. Prepare instead: lower the TTL to a few minutes a day before, make the change, then raise it again. Purging a public resolver helps only the people who use it. Which record does what is in [DNS record types explained](/blog/dns-record-types-explained). --- Canonical page: https://watchfor.io/blog/how-to-check-dns-propagation · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt