DNS Propagation Checker

Introduction

DNS propagation is cache convergence after an authoritative DNS change. The DNS provider may publish a new record immediately, but most visitors do not ask that provider directly. They ask recursive resolvers, and those resolvers can keep an earlier answer until its time to live, or TTL, expires.

That caching delay is why a site move, mail exchanger change, TXT record update, certificate validation record, or CDN cutover can look complete from one network and stale from another. The record is not spreading outward from a central switch. Authoritative nameservers hold the zone data, while recursive resolvers refresh answers according to TTL, cache timing, resolver policy, DNSSEC validation, and sometimes geography.

Authoritative answer

The record published by the DNS provider that serves the zone.

Recursive answer

The answer returned by a resolver after cache, policy, and validation are applied.

RRset

The full set of records for one name and type, such as all A records for www.example.com.

Each record type has its own propagation story. An A record may converge while the matching AAAA, CNAME, MX, TXT, NS, SOA, SRV, or CAA answer is still unchanged. Multi-value records add another common mistake: one missing address, one old mail exchanger, or one absent SPF token can matter even when the overall record type appears to return something.

TTL is the main timing clue, but it is not a shared countdown for every visitor. A resolver may have refreshed the old value seconds before the change. A laptop, browser, office forwarder, ISP resolver, or security gateway may keep its own cache. Negative answers such as NXDOMAIN can also be cached, so a newly created hostname may lag for reasons different from an edited record.

Public resolver agreement narrows uncertainty, but it does not represent every network. Private corporate resolvers, regional ISP caches, split-horizon DNS, browser caches, and location-aware CDN answers can still differ. A strong propagation judgment compares the exact expected RRset, checks holdout TTLs and answer text, and treats DNSSEC or EDNS Client Subnet clues as context rather than proof that every client now sees the same result.

How to Use This Tool:

Start with the exact record you changed, then widen resolver, DNSSEC, and ECS options only when the first snapshot needs more evidence.

1. Enter the Domain as a hostname or URL. URLs are reduced to the host, and the host must be a fully qualified domain name.
2. Choose the Record type: A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, or CAA.
3. Use Expected answer for cutovers, rollbacks, mail changes, and validation records. Leave it blank only when you want to see the largest current answer group.
4. Set Comparison rule to exact text for a full answer, contains text for one token inside a longer answer, or regular expression for a careful pattern.
5. Keep the default Resolvers for a quick public snapshot. Use Select all when you need broader evidence and can tolerate more timeout noise.
6. Use DNSSEC DO bit, DNSSEC CD bit, and EDNS client subnet only when DNSSEC validation or location-sensitive DNS steering is part of the investigation.
7. Review Propagation Brief first. Use Resolver Matrix, Answer Distribution, Resolver Latency, and JSON for row-level evidence, copied CSV, downloadable files, or a diagnostic record.

Interpreting Results:

With an expected answer, the percentage shows how many selected resolvers returned the target under the chosen comparison rule. That is the safest mode for real cutovers because a public resolver majority is not useful if the majority answer is still the wrong value.

Without an expected answer, the percentage shows how many selected resolvers share the largest normalized answer group. Treat that as consensus evidence, then confirm that the lead answer is actually the answer you intended to publish.

• Expected rows match your target. Lead rows belong to the largest answer group when no target is set.
• Different and Other rows are holdouts or alternate answers. Inspect answer text and TTL before assuming they are only slow caches.
• Fail rows did not return a usable answer and still lower the score, because failed evidence should not disappear from the denominator.
• TTL wait is a clue from nonmatching answers. It does not prove when downstream caches, browsers, or clients will refresh.
• AD is a DNSSEC authenticated-data signal from the resolver response. A missing AD value can reflect validation policy, not just propagation lag.

Technical Details:

A recursive resolver may answer from cache until the resource record TTL expires. The TTL value returned by a recursive resolver is usually the remaining cache lifetime for that resolver's current answer, not a promise about every client cache. Separate resolvers can therefore show different TTLs for the same old RRset.

DNS over HTTPS carries the DNS question inside an HTTPS request to a public resolver. Resolver responses may arrive as JSON-style DNS answers or DNS wire-format messages, but the propagation judgment depends on the same evidence: whether a usable answer was returned, what the cleaned answer text is, what TTL was reported, whether AD was present, and how long the request took.

Formula Core:

The score keeps every selected resolver in the denominator, including failed or timed-out rows.

Here s is the number of selected resolvers. With an expected answer, m is the number of rows that match the target. Without an expected answer, m is the size of the largest normalized answer group. For example, 4 matching rows out of 5 selected resolvers produces round(4 / 5 * 100) = 80%.

Rule Core:

Answer normalization removes trailing dots from hostname-style values, strips wrapping quotes from TXT answers, sorts multi-value answers, removes duplicates, and compares the resulting text. That keeps equivalent resolver output from looking different while still preserving meaningful differences in record content.

EDNS Client Subnet can change CDN and latency-sensitive DNS answers because a resolver may send a client-network prefix to an authoritative server. It also has privacy and caching tradeoffs. Cloudflare 1.1.1.1 generally does not forward ECS, while Google Public DNS uses ECS only when the authoritative side implements it correctly. ECS results are therefore resolver-specific evidence, not a universal location test.

Retries repeat failed resolver requests and keep the fastest successful answer for each resolver. Raising timeout and retries can reduce false failures, but it cannot fix an invalid hostname, a wrong record type, a DNSSEC validation problem, or an authoritative zone that has not published the expected RRset.

Privacy and Accuracy Notes:

DNS checks leave the page and are sent to the selected public resolvers. The hostname, record type, DNSSEC choices, ECS value, and request timing can be visible to those providers. Avoid checking private hostnames or sensitive pre-launch names when that disclosure is not acceptable.

A public resolver snapshot cannot represent every user. Local browser caches, operating-system caches, office DNS forwarders, ISP resolvers, split-horizon DNS, and authoritative CDN steering may still produce different answers after the selected resolver set looks aligned.

Worked Examples:

A planned A-record move to 203.0.113.20 should use Record type A and Expected answer 203.0.113.20. If the brief says Mostly propagated to expected value at 80%, and the matrix shows one Different row with an 18-minute TTL, wait for that holdout window and rerun before treating the public recursive view as converged.

A TXT record update for SPF is often easier to validate with Contains text. Checking for include:_spf.example.net can confirm that one required token appears while the matrix still shows the full TXT answer, so missing mechanisms or duplicated fragments remain visible.

If the current verdict is No usable resolver answers, do not read the score as propagation delay. Check that the domain has at least two labels, the record type is correct, the regular expression is valid if used, and the timeout is long enough for the selected resolver set.

FAQ:

Glossary:

AD

Authenticated Data, a DNSSEC-related signal returned by a resolver response.

CD

Checking Disabled, a DNSSEC flag that asks a resolver not to perform validation for the query.

DO

DNSSEC OK, an EDNS flag that requests DNSSEC records and validation context.

ECS

EDNS Client Subnet, an optional subnet hint that may affect location-aware DNS answers.

Recursive resolver

A DNS resolver that answers from cache or performs resolution on behalf of clients.

TTL

Time to live, the number of seconds a DNS answer may remain cached.

References:

• RFC 1035: Domain Names - Implementation and Specification, IETF, November 1987.
• RFC 2308: Negative Caching of DNS Queries, IETF, March 1998.
• RFC 4035: Protocol Modifications for DNSSEC, IETF, March 2005.
• RFC 7871: Client Subnet in DNS Queries, IETF, May 2016.
• RFC 8484: DNS Queries over HTTPS, IETF, October 2018.
• Cloudflare 1.1.1.1 FAQ, Cloudflare.
• EDNS Client Subnet Guidelines, Google Public DNS.
• How to check DNS resolution in Linux, Simplified Guide.
• How to query DNS records in Windows, Simplified Guide.