Free DNS propagation checker — see how your DNS changes look from resolvers worldwide.

Six independent classes of output per propagation check. The per-resolver record list is the obvious headline; the cross-resolver consistency analysis and the TTL exposure are what make this more useful than a flat 'is it propagated yet?' tool.

'DNS propagation' is a misnomer. DNS doesn't push changes outward; it pulls them on demand and caches the result for a TTL. What feels like propagation is actually the worldwide expiration of cached old records. Five things to understand:

• Authoritative changes are instant. When you update a DNS record at your provider, the authoritative nameserver has the new record immediately. Nothing 'propagates' from there — the change is done at the source as soon as the provider's API confirms.
• Resolvers cache for TTL seconds. What delays the change reaching users is recursive-resolver caching. Every resolver that already queried the old record holds it for its TTL (the value in seconds set by your provider — often 300 to 86400). Until that TTL expires, the resolver serves the old answer to its users.
• Different resolvers cached at different times. A resolver that last queried 5 minutes ago shows old. A resolver that last queried 23 hours ago is about to refresh. Resolvers in regions with little traffic to your domain might not have it cached at all and will fetch fresh on first query. This is why 'propagation' looks geographically uneven.
• Lowering TTL beforehand controls the window. If you know you're going to change a record, drop its TTL to 60 or 300 a few days in advance. After the old TTL expires across all resolvers, change the record. Now the worst-case delay for the new record is your new (low) TTL — minutes, not hours. Critical for high-stakes migrations.
• Some clients ignore TTL. Browsers, OS resolvers, and corporate proxies sometimes cache DNS results longer than TTL or shorter. Chrome caches DNS internally for 60 seconds regardless of TTL. Stub resolvers in some operating systems cache for the full TTL. End-to-end propagation is bounded by the longest cache in any client's path — sometimes longer than just the recursive-resolver TTL.

Each check fans out queries to dozens of public resolvers in parallel, gathers the answers, and compares them. No intermediate cache, no rate-limited proxy — direct connections to each resolver's published IP from regionally-distributed infrastructure.

• Stage 1 — Build the resolver list Pre-curated list of 30+ public resolvers across 6 continents. Major operators (Google 8.8.8.8/8.8.4.4, Cloudflare 1.1.1.1/1.0.0.1, Quad9 9.9.9.9, OpenDNS 208.67.222.222) plus regional resolvers known to be geographically distinct.
• Stage 2 — Parallel query fan-out Send the same DNS query to every resolver in parallel. Total wall-clock time is bounded by the slowest resolver, not the sum of all of them. Median full sweep: under 4 seconds.
• Stage 3 — Collect answers + metadata Each resolver returns: the answer record(s), the remaining TTL (signaling how recently the resolver fetched), and per-query response time. Failed responses (timeout, REFUSED, SERVFAIL) are captured as-is — they're useful signal too.
• Stage 4 — Group by answer Cluster resolvers by the value they returned. If most return `93.184.216.34` and a handful return `192.0.2.1` (the old value), the groups are obvious. Visualized as a world map with color-coded markers.
• Stage 5 — Compute propagation percentage Most-common answer / total responding resolvers = propagation %. Anything below 100% means at least one resolver is still serving an alternative answer. The 'right' answer is the new one — but the tool just reports majority; you decide which is current.
• Stage 6 — Per-resolver detail view Drill into any individual resolver to see its exact answer, TTL remaining, response time, and IP. Useful when investigating why a specific region or ISP is seeing stale records.

TTL (Time-To-Live) is the number of seconds a recursive resolver may keep a record cached before re-querying the authoritative nameserver. It's the single biggest knob you control on propagation speed. Six things to know:

• TTL is set by you, at the authoritative nameserver When you create a record in your DNS provider's UI, you choose the TTL (some providers default to 3600 or 86400). Recursive resolvers respect that value when caching the answer.
• Low TTL = fast propagation, more queries TTL=60 means resolvers re-fetch every minute. Changes propagate in ~1 minute worldwide. Cost: more queries hit your authoritative nameservers — and most authoritative-DNS pricing is per-query.
• High TTL = slow propagation, fewer queries TTL=86400 (24h) means resolvers cache for a day. Changes can take up to 24h to fully propagate. Cost: cheap to operate; great for stable records (NS, MX, static A records that don't move).
• The pre-change TTL drop Standard maintenance pattern: drop TTL to 60 or 300 at least 'old TTL' seconds before the change. Wait for the old TTL to fully expire (the longest any resolver can hold the old value). Make the change. The new value now propagates within the new low TTL. After 24h at the new value, raise TTL back to normal to reduce query load.
• TTLs vary by record type purpose Common conventions: A/AAAA = 300 to 3600 (medium — these change occasionally). NS = 86400 (day — delegation should be stable). MX = 3600 (hour — moderately stable). TXT used for verification = 300 (low — added and removed often). SOA TTL = stable, since the SOA itself controls negative caching.
• Negative caching (NXDOMAIN TTL) When DNS returns 'no such record' (NXDOMAIN), resolvers also cache that absence — for the SOA's minimum TTL, not the record's TTL. This is why a newly-added record can take a while to appear: if a resolver cached the 'doesn't exist' response, that cache must expire before the new record is visible. Set the SOA minimum TTL low if you frequently add new records.

Six patterns we see most often:

Every resolver's answer, TTL, and latency is available as JSON. Useful for automated migration scripts, CI-gated DNS deploys, and continuous propagation monitoring during a rollout window.

curl 'https://api.domainscan.in/v1/domain/propagation?domain=google.com&type=A'

const res = await fetch(
  'https://api.domainscan.in/v1/domain/propagation?domain=example.com&type=A'
);
const prop = await res.json();

console.log(prop.summary.propagationPct);    // 96.5
console.log(prop.summary.totalResolvers);    // 30
console.log(prop.summary.consistent);        // false

// Which resolvers are out of sync
const majority = prop.summary.majorityAnswer;
prop.resolvers
  .filter(r => r.answer !== majority)
  .forEach(r => console.warn(`${r.name} (${r.region}) still showing ${r.answer}`));

// Wait for 100% in a deploy script
if (prop.summary.propagationPct < 100) {
  process.exit(1);   // re-run on retry
}

{
  "domain":     "example.com",
  "recordType": "A",
  "resolvers": [
    {
      "name":        "Google Public DNS",
      "ip":          "8.8.8.8",
      "region":      "Global (Anycast)",
      "answer":      ["93.184.216.34"],
      "ttl":         3600,
      "responseMs":  18,
      "status":      "ok"
    }
  ],
  "summary": {
    "totalResolvers":   30,
    "responding":       30,
    "majorityAnswer":   ["93.184.216.34"],
    "propagationPct":   100,
    "consistent":       true,
    "medianResponseMs": 22
  }
}

• What is DNS propagation? DNS doesn't really 'propagate' — the authoritative server has the new record instantly. What feels like propagation is the global expiration of cached old records at recursive resolvers worldwide. Each resolver holds the old record until its TTL expires, then re-fetches the new one. Worldwide consistency is reached when every resolver that had the old value cached has expired and re-queried.
• How long does DNS propagation take? It depends on the TTL of the record. TTL=60 means full propagation in about 1 minute. TTL=3600 (1 hour) means up to 1 hour. TTL=86400 (24 hours) means up to 24 hours. Most providers default to 1-24 hour TTLs. Browsers and OS-level resolvers add additional caching layers that can extend the worst-case delay slightly.
• Why is my DNS not propagating? Almost always TTL caching. The record is correct at the authoritative server; resolvers between you and the server are still serving stale data until their cached TTL expires. Confirm by querying the authoritative nameserver directly (the DNS Query tool does this). If authoritative is correct but resolvers show stale data, just wait for TTL expiry.
• How do I speed up DNS propagation? You can't make currently-cached records expire faster — once a resolver has cached, you wait. What you can do beforehand: drop the TTL of the record to a low value (60 to 300 seconds) at least one old-TTL-duration in advance. When you make the actual change later, the worst-case propagation is bounded by the new low TTL.
• Why are some resolvers showing new records and others old? Different resolvers cached the old record at different times — based on when their first user queried it. A resolver that hit your domain 23 hours ago is about to refresh; a resolver that hit it 1 hour ago has 22+ hours of cache left. Geographic distribution looks uneven because population and traffic patterns are uneven. Wait for TTL expiry across all resolvers, and it converges.
• What's the difference between propagation and an NS lookup? NS lookup queries the authoritative nameserver directly — bypassing all caching, you get the source-of-truth answer. Propagation check queries dozens of recursive resolvers worldwide to see what each is currently returning — including stale caches. Both are useful for different questions: NS lookup confirms the record is correct at the source; propagation check confirms the rest of the internet is also seeing it.
• Why does my browser still see the old DNS after the resolver updated? Browsers add their own DNS cache layer — Chrome caches for 60 seconds regardless of TTL. The OS may also cache. So even after the recursive resolver updates, your specific browser might serve old DNS for another minute. Clear the browser's DNS cache (chrome://net-internals/#dns) and the OS DNS cache (`ipconfig /flushdns` on Windows, `sudo dscacheutil -flushcache` on macOS) to force a fresh lookup.
• What is a public DNS resolver and which ones are reliable? A public DNS resolver is a recursive nameserver operated for general use, free of charge, by a major operator. Most reliable: Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), Quad9 (9.9.9.9), OpenDNS (208.67.222.222). Each has globally-distributed anycast infrastructure and is more reliable than typical ISP resolvers. This tool queries all of them and reports each one's view.