DNS Propagation Checker

Run this tool

Input or start condition: Enter the labeled value and submit it. The lookup is idle without a valid query parameter.

Accepted input or signal: Domain name, Submitted public lookup target.

Possible output: A, AAAA, MX, NS, TXT, CNAME, or CAA answers returned by five public recursive resolver endpoints.; Resolver-by-resolver success, no-data, timeout, or error status with response duration.

Key limitation: Changing a record's TTL after an update does not shorten the lifetime of copies already cached under the old TTL.

What this checks

• A, AAAA, MX, NS, TXT, CNAME, or CAA answers returned by five public recursive resolver endpoints.
• Resolver-by-resolver success, no-data, timeout, or error status with response duration.
• The number of responding resolvers and the distinct normalized answers observed in the comparison.

How to interpret results

• Matching answers across all responding resolvers are consistent evidence that widely used caches see the same record.
• Mixed old and new answers usually indicate TTL-based cache refresh in progress, but can also reveal inconsistent authoritative servers.
• A no-data response is different from a timeout: the resolver answered, but the selected record type was absent.

Common issues

• Changing a record's TTL after an update does not shorten the lifetime of copies already cached under the old TTL.
• Five resolvers provide a useful comparison, not an exhaustive measurement of every network or geographic region.

How to verify a DNS change

Select the record type you changed and compare every resolver row. For A or AAAA changes, verify the exact address. For MX and NS changes, compare both the target names and any priority values returned in the answer.

If some rows still show the old answer, wait at least the previous record's TTL before declaring a propagation fault. If the mismatch persists, query the authoritative name servers with DNS Lookup and compare their answers directly.

Propagation versus authoritative inconsistency

Propagation is cache convergence: recursive resolvers refresh data after its TTL expires. Authoritative inconsistency is different—two authoritative servers may be serving different zone versions, so fresh recursive queries can continue to disagree.

Repeated mixed answers after the expected TTL window are a reason to inspect the zone serial, delegation, and authoritative server responses rather than waiting indefinitely.

Privacy note

The entered domain and selected record type are sent to the site's server, which performs the requested lookups against public recursive DNS resolvers. Results are not intended for user profiling.

Frequently Asked Questions

What does a DNS propagation checker compare?

It sends the same record query to five public recursive resolver endpoints and shows each status, response time, answer set, and the unique answers seen across them.

Why do DNS resolvers show different answers?

Resolvers can hold records cached at different times, authoritative servers can answer inconsistently, and a recent TTL or delegation change may not have reached every cache yet.

How long does DNS propagation take?

There is no universal delay. Existing cache TTLs, negative caching, delegation TTLs, and authoritative-server consistency determine when resolvers refresh their answers.