# DNS Propagation Checker

> Queries every authoritative nameserver, compares them against more than 170 observation points in over 70 countries, reads each cache's remaining TTL and separates stale cache from GeoDNS.

Free in-browser tool (no upload): https://www.mauriziofonte.it/tools/dns-propagation-checker

Queries the zone's **authoritative nameservers** and compares them against an inventory of more than 170 observation points in over 70 countries, revalidated every day. For each cache it shows the **remaining TTL**, meaning the seconds left before it expires, and separates two situations that look alike: a cache still serving the previous value, and a CDN-backed domain that answers different addresses to different networks.

## How to use it

1. **Enter the domain** - A full URL or an email address works too: the hostname is extracted. Internationalised domains are converted to punycode automatically.
2. **Pick the record type** - A and AAAA for where the site points, MX for mail, TXT for SPF, DKIM and ownership verification, NS for a nameserver change, CNAME for aliases. CAA, DS, DNSKEY, TLSA, SRV, SVCB and HTTPS are covered too.
3. **Leave the authoritative plane on** - Direct queries to the zone's nameservers provide the reference used to judge the caches. Without them the values are readable but the comparison is not.
4. **Read each row's verdict** - Every row carries a class and the reason it was assigned. An answer that differs from authoritative can be perfectly normal: it happens on every CDN-served domain.
5. **Watch the time remaining** - If a cache is still serving the previous value, the countdown shows when the last observed one expires. After that, propagation is complete across the measured points.

## Why resolvers return different values

People who reach a tool like this usually ask **"is my DNS change done, and if not, when will it be?"**. Many tools answer another question instead: "which addresses do twenty resolvers return". Those are different questions, and the first does not answer the second.

Divergent answers between resolvers have two distinct causes. The first is **caching**: a resolver stored the previous value before the change and keeps serving it until the TTL expires. That is propagation in progress, and the time left is a readable number. The second is **geographic routing**: the domain is served by a CDN or a load balancer that answers different addresses depending on the network the query comes from. In that case nothing is updating and there is nothing to wait for.

A measurable example on this very domain, with publication finished months ago: the authoritative nameservers answer `172.67.135.235` and `104.21.7.88`, while `8.8.8.8` and `9.9.9.9` answer `188.114.96.7` and `188.114.97.7`. Different addresses, same operator, anycast network. Read without context, that difference looks like a change that has not propagated yet.

The two cases can be told apart by observation. **A cache serving a superseded value necessarily has an already-consumed TTL**, because it was populated before the change and time passes; an answer just fetched from the origin arrives with a full TTL. So a different value with a full TTL indicates the origin answered that way just now, while a different value with an eroded TTL indicates a previous copy still in circulation, and the seconds left are the remaining TTL.

On top of that reading sits a direct check, when it can be obtained: query the authoritative nameserver with different **EDNS Client Subnet** values and see whether the answer changes. If it does, geographic routing is detected. If it does not, nothing is concluded, because several CDNs implement geography through nameserver anycast rather than ECS.

## Glossary

- **DNS propagation**: Informal name for the gradual expiry of resolver caches after a change. There is no distribution process: previous copies simply expire.
- **TTL**: Time To Live, the number of seconds a record may stay cached. The TTL a resolver returns is the time left on its copy, not the value configured in the zone.
- **Authoritative nameserver**: The server holding the zone, answering with the AA bit set. It is the source of the data: everything else is a copy with an expiry.
- **SOA serial**: The zone's version number. If two authoritative nameservers of the same provider report different serials, one of them has not received the latest version.
- **Anycast**: One IP address announced from many data centres; the nearest one to the asker replies. It is why a public resolver's IP does not identify a place.
- **GeoDNS**: A setup where the authoritative server answers different values depending on where the query comes from. It produces stable, expected divergence between resolvers.
- **EDNS Client Subnet**: An extension (RFC 7871) that lets a resolver tell the authoritative server the client's subnet. Querying with different ECS values makes geographic routing detectable.
- **Negative caching**: Recording that a name does not exist. It lasts as long as the SOA minimum field, which is why a freshly created record can stay invisible for a few minutes.
- **DNSSEC**: Cryptographic signing of the zone. If validation fails, a validating resolver returns SERVFAIL and the domain is unreachable for its users, regardless of propagation.
- **Delegation**: The NS records the registry publishes for the zone. Incomplete delegation produces intermittent resolution, which downstream resembles slow propagation.
- **CNAME**: An alias to another name. The final records live in the target's zone, so the authoritative check follows the chain to that zone.

## Frequently asked questions

### How long does DNS propagation take?

As long as the record's TTL, plus the time the provider needs to publish the change on the authoritative servers. With a 300 second TTL that means five minutes. The "24 to 48 hours" answer dates back to when TTLs were far longer and some ISPs did not honour their expiry: today it is rarely relevant.

### Why do two resolvers give me different addresses even though I changed everything days ago?

In most cases because the domain is served by a CDN or a geographic load balancer that answers different addresses to different networks. It happens with Cloudflare, Akamai, Fastly and latency-based Route53. This tool classifies those rows as a geographic variant, so the difference stays readable without resembling an incomplete change.

### Can I force propagation or flush the caches?

You can flush your own operating system and browser caches, and use the public flush forms Google and Cloudflare provide for their own resolvers. On other resolvers the copy refreshes when the TTL expires: there is no mechanism to bring that forward from the outside.

### How do I prepare a DNS change to shorten the window?

Lower the record's TTL to 300 seconds at least 24 hours before the change, wait for the previous TTL to expire, perform the migration, verify, and only then raise the TTL back to its usual value. That is the procedure that reduces the misalignment window to a few minutes.

### Why does querying authoritative nameservers need a server?

Because authoritative nameservers speak DNS over UDP and TCP port 53: they do not expose DNS-over-HTTPS and send no CORS headers, so a browser cannot reach them. The rest of the tool runs in the browser; if querying the nameservers does not answer, the result says so and the measurements from your network remain valid.

### What does it mean when SOA serials differ?

That the zone's nameservers do not all hold the same version of the data: one or more secondaries have not received the latest transfer. There is a common case to distinguish, though: if the zone is served by two separate providers, each uses its own numbering and the serials are not comparable. This tool compares them only within the same master declared in the SOA.

### I just created the record and some resolvers say it does not exist. Is that normal?

Yes, this is negative caching: that resolver had already been asked for the name before it existed, stored the negative answer and keeps it for the period given by the SOA minimum field, typically a few minutes to an hour.

### How many observation points are queried?

It depends on the profile. The quick one, the default, queries about thirty: the large anycast operators plus a geographic sample spread across the continents. The full one queries the whole active inventory, more than 170 points in over 70 countries. Either way the zone's authoritative nameservers are added, since they are the reference, and the "where these measurements come from" section reports the exact count of the moment and the date of the last validation. The per-operator count stays the informative one: an operator's primary and secondary share infrastructure and policy, so they do not constitute two independent viewpoints.

### Why is there no world map?

Because public resolvers are anycast: the same IP address is announced from hundreds of data centres and the nearest one to the asker replies, so tying it to a city would not describe the query's actual path. What is stated here is where each measurement starts from: your browser for the first plane, a server in Germany for the second.

### Is the domain I check stored anywhere?

No. The measurement from your network never touches any server of this site. Querying the nameservers goes through an endpoint that caches the result for twenty-five seconds, to avoid repeating the same queries, and does not record the domain queried. There is no history and no account.

### Can I add my own resolver?

Yes, up to three public IP addresses. Private addresses are not accepted: an internal resolver would not be reachable from the server running the queries, and accepting them would open the door to probing private networks. For an internal resolver the right tool is dig, from the network it lives in.

### Does it work with CDN-backed domains?

Yes. If the name is an alias, the check follows the CNAME chain to the zone holding the final records and measures there. The result shows the chain followed and the zone actually queried, which for a CDN-backed name differs from the domain you typed.

### Does it work for mail and certificates too?

Yes. MX for mail routing, TXT for SPF and DKIM, CAA for the authorities allowed to issue certificates, TLSA for DANE, SVCB and HTTPS for the records used by ECH and Alt-Svc. For a full mail-record analysis there is the [email DNS validator](/tools/email-dns-validator).

---
Tool by Maurizio Fonte, senior backend engineer. All tools: https://www.mauriziofonte.it/tools/