DNS propagation checker

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.

How to use it

1. Enter the name and record typeUse 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 firstThe 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 againResolvers 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.

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.

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 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.

# 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. Standards: RFC 1034 and RFC 1035 (resolution and caching), RFC 2308 (negative caching), RFC 8767 (serving stale data) and RFC 9499 (terminology).