# DNS Propagation Checker

Ask dozens of public DNS resolvers (anycast services and regional/ISP resolvers in many countries) for the same record and compare the answers with the authoritative nameserver or an expected value. Returns per-resolver status (current, stale, empty, nxdomain, servfail, timeout), answers, remaining TTL and latency, the distinct answer sets with how many resolvers serve each, a one-line verdict and when stale caches should expire. Returns what finished at the deadline with incomplete=true. Use it after changing A, CNAME, MX, NS or TXT records.

**Not for:** A single quick lookup (use dns_lookup) or checking SPF/DMARC syntax.

- Tool id: `dns-propagation`
- Category: dns
- Execution: fanout
- MCP tool `dns_propagation` at https://lookupowl.com/mcp
- REST `GET https://lookupowl.com/api/v1/tools/dns-propagation` (or POST a JSON body)
- OpenAPI: https://lookupowl.com/api/openapi.json

## Input

| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| `name` | string | yes |  | Host name to check, e.g. www.example.com. A URL or e-mail address is reduced to its host; Unicode names are converted to Punycode. max length 253 |
| `type` | "A" \| "AAAA" \| "CNAME" \| "MX" \| "NS" \| "TXT" \| "SOA" \| "CAA" \| "SRV" \| "DS" \| "DNSKEY" \| "HTTPS" | no | `"A"` | Record type to compare across resolvers. |
| `expected` | string | no |  | The value you expect to see after your change, e.g. a new IP address. Resolvers whose answers include it count as current. For address and name records the whole value must match; for TXT and other text records a substring is enough. Without it the authoritative answer is the reference. max length 512 |

## Output

Results are wrapped in an envelope: `tool`, `version`, `requestId`, `data`, `summary`, `meta` (cache status, timing), `permalink`. `data` has these fields:

| Field | Type | Description |
|---|---|---|
| `name` | string |  |
| `type` | string |  |
| `expected` | string |  |
| `reference` | object |  |
| `authoritative` | object[] |  |
| `resolvers` | object[] |  |
| `counts` | object |  |
| `consensus` | object |  |
| `summary` | string |  |
| `eta` | string |  |
| `etaSeconds` | integer | Longest remaining TTL among stale resolvers: when the old answer should be gone. min -9007199254740991, max 9007199254740991 |
| `minTtl` | integer | min -9007199254740991, max 9007199254740991 |
| `flushLinks` | object[] |  |
| `incomplete` | boolean | The deadline passed before every resolver answered; see pending. |
| `pending` | string[] | Ids of resolvers that had not answered when the deadline passed. |
| `notes` | string[] |  |

## Examples

### A record of example.com

```json
{"name":"example.com","type":"A"}
```

```bash
curl 'https://lookupowl.com/api/v1/tools/dns-propagation?name=example.com&type=A'
```

Web page: https://lookupowl.com/dns-propagation-checker?q=example.com

### MX records of google.com

```json
{"name":"google.com","type":"MX"}
```

```bash
curl 'https://lookupowl.com/api/v1/tools/dns-propagation?name=google.com&type=MX'
```

Web page: https://lookupowl.com/dns-propagation-checker?q=google.com&type=MX

### Nameservers of cloudflare.com

```json
{"name":"cloudflare.com","type":"NS"}
```

```bash
curl 'https://lookupowl.com/api/v1/tools/dns-propagation?name=cloudflare.com&type=NS'
```

Web page: https://lookupowl.com/dns-propagation-checker?q=cloudflare.com&type=NS

### Has my new IP arrived?

```json
{"name":"example.com","type":"A","expected":"93.184.216.34"}
```

```bash
curl 'https://lookupowl.com/api/v1/tools/dns-propagation?expected=93.184.216.34&name=example.com&type=A'
```

Web page: https://lookupowl.com/dns-propagation-checker?q=example.com&expected=93.184.216.34

## Web pages

- https://lookupowl.com/dns-propagation-checker

## Limits and caching

- Cost: 12 units for a live lookup, 1 unit for a cached one. Budgets are per network and published in the `RateLimit` response headers.
- Cache: the lifetime follows the data (for DNS, the record TTL, within a few minutes). Add `fresh=true` (MCP argument or query parameter) to look again; it costs 3 units per unit and is limited to 10 per hour.
- Timeout: 9 s.

## Related tools

- [DNS Lookup](https://lookupowl.com/tools/dns-lookup.md): Look up A, AAAA, MX, NS, TXT, CNAME, SOA, CAA, DS and DNSKEY records from a public resolver or the authoritative nameserver.
- [Reverse DNS Lookup](https://lookupowl.com/tools/reverse-dns.md): Find the host name (PTR record) of an IPv4 or IPv6 address and check that it resolves back to the same address.
- [WHOIS Lookup](https://lookupowl.com/tools/whois-lookup.md): Registrar, creation and expiry dates, status codes, nameservers and DNSSEC for any domain, from RDAP with WHOIS fallback.
- [SPF Record Checker](https://lookupowl.com/tools/spf-checker.md): Check a domain's SPF record, count its DNS lookups against the limit of 10 and find errors.
- [DMARC Record Checker](https://lookupowl.com/tools/dmarc-checker.md): Look up and validate a domain's DMARC policy, report addresses and alignment settings.

## Guide: DNS propagation checker

See which resolvers around the world have picked up your DNS change, and which are still holding on to the old answer.

### What this checker shows

After you change a DNS record, some people see the new value straight away while others keep seeing the old one for hours. This checker asks 48 public resolvers, from big services such as Google and Cloudflare to ISP and regional resolvers in about 25 countries, for the same record. It also asks the domain's own nameserver, then lines the answers up side by side. A resolver that gives the same answer as the nameserver is up to date. One that doesn't is probably still serving a cached copy.

> **Propagation is really caching** DNS changes do not spread outward. The authoritative nameserver has the new value as soon as your DNS host publishes it. Everyone else keeps the old answer until its time to live (TTL) runs out, then asks again. “Propagation time” is simply how long the slowest cache takes to expire.

### How to use it

1. **Enter the name and record type**: Use the exact hostname people visit, not just the domain. For a website check `A` or `CNAME`, for email check `MX` on the domain, and for a verification token check `TXT`. The type menu is in More options and starts on `A`.
2. **Add the value you expect (optional)**: In More options, enter what you changed the record to: an IP address for `A` or `AAAA`, a hostname for `CNAME`, `NS` or `MX`, or any piece of the text for `TXT`. Resolvers that return it count as current, so you can see at a glance whether your change has arrived. Without it, resolvers are compared with the nameserver's answer.
3. **Check the nameserver first**: The Authoritative tab shows what the domain's own nameserver returns. If that is not your new value (the result says so when you entered one), the change is not published at your DNS host yet, and waiting for caches will not help.
4. **Run it again**: Resolvers switch from old to new as their caches expire. Use Check again every few minutes (a result is cached for up to two minutes) and watch the count of current resolvers. You don't need every one. What matters is the resolvers your visitors use.

> **Ask an AI assistant** With the LookupOwl MCP server connected, try: “Has the new A record for shop.example.com reached public resolvers yet?” The assistant calls `dns_propagation` and tells you which resolvers are still on the old answer.

### How to read the results

The top of the result is a headline such as “Almost there: 43 of 48 are current”, with a sentence beneath it that says what the resolvers were compared with. Beside it are a roll call with one dot per resolver, the answers grouped with a count for each, and a map, so a split between old and new is easy to spot. Three tabs hold the detail: the resolvers by region, the authoritative nameserver, and links to refresh the big public caches.

| Result | Meaning | What to do |
|---|---|---|
| Current | The resolver gives the same answer as the nameserver, or contains the value you expect. | Nothing. |
| Old answer | The resolver still has a cached copy. It reads Different answer when there is no nameserver answer or expected value to compare with. | Wait for the old TTL, shown beside it, or use the refresh links on the Speed it up tab. |
| Several different answers | Load balancing, a CDN or geo-DNS (DNS that answers by location) can give each resolver a different valid address. Without an expected value the checker cannot tell that from a stale cache, but it adds a note when it sees three or more answers. | For your own records, enter the value you expect. For CDN-hosted names, differences are normal. |
| Not found or No records | The resolver believes the name does not exist, or has no record of this type, possibly from a cached negative answer. | Wait for the zone's negative-cache time (the SOA minimum), shown in the [SOA lookup](https://lookupowl.com/soa-lookup). |
| Server failure, Refused, No answer or Error | The resolver could not complete the lookup. | Check the domain's nameservers and DNSSEC. One slow resolver is not a global problem. |

When the nameserver returns your expected value, or the record has been removed, the result adds a Fully settled in time. That is the longest remaining TTL among the resolvers still on the old answer. Without one of those two, a different answer could be perfectly legitimate, so the checker does not promise a time.

The longest anyone should wait is roughly the **old** record's TTL after the change. Nameserver changes are slower. The registry publishes your nameservers with its own TTL, two days for .com and .net (some endings use less), so resolvers can keep using the old ones for that long.

### When it still looks wrong

- **The nameservers disagree.** If your DNS host runs several nameservers, one may not have the update yet. LookupOwl asks one of them, chosen at random, so compare them all with `dig +nssearch` and look at the serial numbers (command below).
- **The new record isn't showing anywhere.** You may have edited the zone at a host that is not the delegated one. Check the [NS records](https://lookupowl.com/ns-lookup) and your registrar.
- **The resolvers are right but your computer isn't.** Your operating system, browser and router cache DNS too. Flush them with the commands below.
- **The site still shows old content.** The address may be new, but a CDN, your browser's cache or an entry in your `hosts` file can still send you to the old server.
- **A filtering resolver is the odd one out.** Six of the 48 block malware, ads or adult content by policy and are marked Filters content. A missing answer there can be a block rather than a stale cache.
- **An anycast resolver differs from what a visitor sees.** Services such as 8.8.8.8 and 1.1.1.1 are many servers behind one address. The checker reaches the one nearest LookupOwl's servers, so someone in another country could briefly see something else.
- **A long TXT answer comes back cut short.** Resolvers sometimes return only part of a big set of records. The checker notes when a resolver returned only part of the nameserver's set, because that is not a stale cache.

```bash
# Compare the serial number on every nameserver
dig +nssearch example.com

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
resolvectl flush-caches

# Chrome's internal cache
chrome://net-internals/#dns
```

The big public resolvers also let you ask them to forget one name. Google Public DNS and Cloudflare 1.1.1.1 have cache purge pages, and Cisco OpenDNS has a cache check page. All three are linked from the Speed it up tab.

### How the check works

LookupOwl asks the domain's own nameserver, with no cache in between, to get the baseline. At the same time it sends the same question to the 48 resolvers, 16 at a time, and gives each two seconds to answer. A resolver that fails becomes a row in the table, not an error. If the whole check hits its limit of about eight seconds, you get whatever has finished, marked incomplete. Results are cached for up to two minutes, so repeat checks stay fresh without hammering anyone. Fresh checks of any one domain are limited to 30 a minute across all callers, so the tool cannot be used to flood someone's nameservers.

Background: [how DNS propagation works](https://lookupowl.com/learn/dns-propagation). Standards: **RFC 1034 and RFC 1035** (resolution and caching), **RFC 2308** (negative caching), **RFC 8767** (serving stale data) and **RFC 9499** (terminology).

### Frequently asked questions

**How long does DNS propagation take?**

Usually minutes to a few hours: as long as the old record's TTL. If the old TTL was 300 seconds, expect about five minutes, and if it was a day, plan for a day. Changing nameservers is the slow case and can take up to 48 hours.

**Why do different locations show different results?**

Each resolver has its own cache, filled at different times, so in the hours after a change some hold the new value and others the old one. Some answers also depend on location by design, as with CDNs and geo-DNS, and that is not a propagation problem.

**Can I speed up DNS propagation?**

Not for caches you don't control, but you can prepare. Lower the TTL a day or two before a planned change, make the change, then raise the TTL again. Afterwards, flush your own device's DNS cache and use the purge pages of the big public resolvers, which are linked from the result.

**Do I have to wait for 100 percent?**

No. Once the nameserver returns the right value and the resolvers your users rely on have updated, you can carry on. Long-tail resolvers with large TTLs will catch up on their own, and a few of the 48 may time out on any given run.

**Why is my email still going to the old server?**

Sending mail servers and their resolvers cache your `MX` records until the old TTL runs out, so some mail keeps going to the old server until then. Keep the old mailbox running for at least that long, and check the `MX` record here to see who has updated.

**Does it check both IPv4 and IPv6?**

It checks one record type at a time, so run `A` for IPv4 and `AAAA` for IPv6 separately. A site can be updated for one and not the other. A site with no `AAAA` record at all simply does not use IPv6, which is normal.

**Is this tool free to use through the API?**

Yes. The `dns_propagation` tool is on the free REST API and the MCP server, with no key needed and fair-use limits. You can call the API once per record type, or ask an assistant in plain language, as in the tip above. See the [terms](https://lookupowl.com/terms).