Global DNS Propagation
{{ propagationPercent }} %
Majority: {{ majorityAnswer }} {{ propagatedCount }} / {{ results.length }} resolvers {{ answerStats.unique }} unique answers {{ answerStats.fail }} failures
Last run: {{ lastRunLocal }}
{{ resolver_keys.length }} / {{ resolverCatalog.length }} selected
ms
{{ resolver_keys.length }} resolvers DO {{ dnssec_do ? 'on' : 'off' }}, CD {{ dnssec_cd ? 'on' : 'off' }} ECS {{ ecs }} {{ timeout_ms }} ms {{ retries }} retries
# Resolver Answer TTL AD Time (ms) Copy
{{ i+1 }} {{ row.resolver }} {{ row.answer || '—' }} {{ row.ttl !== null ? row.ttl : '—' }} {{ row.ad === true ? '✔' : (row.ad === false ? '✖' : '—') }} {{ row.ms !== null ? row.ms : '—' }}
No data.

      
:

Introduction:

Domain name records describe where a name points and how that name should be handled. Propagation is the pace and consistency with which updates appear across the world, and a global domain name propagation checker helps you see agreement at a glance.

The checker queries a range of public resolvers and condenses their answers into one percentage that is easy to read and compare. You can use that number to judge when a change is broadly visible so a cutover is less risky.

You provide a full domain such as example.com and choose a record type like A or MX. You may also enable integrity checking and an optional client subnet hint to compare how different networks would be steered.

For example you switch a mail record to a new provider and run a check after ten minutes. Most resolvers return the new target and the percentage climbs to 80 to 95 then you can schedule the switchover.

Propagation is not instant and cached answers can persist beyond expectations. Treat the percentage as a guide and verify with sample clients in the regions that matter most.

Technical Details:

The Domain Name System (DNS) maps hostnames to resource records, which are the structured answers returned by resolvers. Each response also carries a time to live value indicating how long the answer may be reused without asking again.

The checker evaluates three outcomes from the selected resolvers: the majority answer string, the proportion that match that majority expressed as a percentage, and the per‑resolver response time measured in milliseconds. When the percentage is high, the chosen resolvers agree on one answer; when it is low, answers are mixed or failing.

Responses can include an authenticated data flag when integrity validation is active. If a client subnet hint is supplied, some resolvers may tailor answers to that network, which affects the distribution you observe.

Comparisons are limited to the resolvers you select. Each resolver reflects one of its global nodes, so results summarize those vantage points rather than every internet provider cache.

p = round ( n N × 100 )
Symbols and units
Symbol Meaning Unit/Datatype Source
p Propagation percentage percent Derived
n Resolvers matching the majority answer count Derived
N Resolvers queried count Selection
tms Per‑resolver response time ms Derived
TTL Minimum time to live across returned records seconds Derived
AD Authenticated Data flag from the resolver boolean Derived
rr Record type enumeration Input
Worked example. Suppose N = 7 resolvers reply and 6 share the same answer. Then
p = round ( 67 × 100 ) = 86
Interpretation: most selected resolvers have the change, but a few still hold older data.

Processing pipeline

  1. Normalize the domain by removing any trailing dot.
  2. Validate label count and label characters.
  3. Build one HTTPS JSON query per resolver with chosen flags.
  4. Send all queries concurrently with a per‑resolver timeout.
  5. Retry each resolver the chosen number of times.
  6. Pick the fastest successful attempt for each resolver.
  7. Parse answers, strip quotes from text, and drop trailing dots.
  8. Compute the minimum TTL across returned records.
  9. Aggregate majority text, counts, percentage, and timings.

Validation & bounds

Input validation and limits
Field Type Min Max Step/Pattern Error Text / Notes
Domain FQDN 2 labels 253 chars Each label 1 to 63, letters digits and dash, not starting or ending with dash “Enter a valid domain (FQDN).” Trailing dot removed before query.
Record type Enum A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, CAA Used as the query type.
Timeout Number 500 Step 100 ms Per‑resolver cutoff in milliseconds.
Retries Integer 0 Step 1 Additional attempts per resolver.
Integrity flag Boolean Requests integrity records Enables AD reporting when supported.
Checking disabled flag Boolean Ask resolver not to set AD For comparative testing of validation paths.
Client subnet Text (CIDR) Example 0.0.0.0/0 or 2001:db8::/32 Optional; string is passed as provided.

I/O formats & encoding

Input and output formats
Input Accepted Families Output Encoding/Precision Rounding
Domain, record type, optional flags Text domain; record type enum Table of answers and timings; summary percent; charts JSON copy and download, CSV copy and download Percent rounded to nearest integer

Networking & storage behavior

  • Queries are sent over HTTPS to public JSON endpoints of selected resolvers.
  • Supported resolvers include Cloudflare, Google, Quad9, AdGuard, DNS.SB, AliDNS, and OpenDNS.
  • Query parameters include name, type, a fixed content type for JSON, plus optional integrity and client subnet hints.
  • No server‑side storage is used; processing and aggregation occur in the browser.

Performance & complexity

Requests run concurrently across resolvers. Work scales linearly with the number selected. Timeouts and limited retries cap worst‑case latency.

Diagnostics & determinism

Given identical inputs and current resolver states, the checker yields the same aggregation. Network timing and upstream caches introduce normal variability.

Security considerations

Queries reveal the domain and type to public resolvers. Avoid entering sensitive internal names. Integrity flags expose whether validation was performed, but do not enforce it end‑to‑end.

Assumptions & limitations

  • Heads‑up Majority agreement does not guarantee reachability of the target host.
  • TTL is the minimum across returned records and may understate some entries.
  • Resolvers may serve differing answers by design for load steering.
  • Anycast vantage points are sampled, not every city or provider.
  • Client subnet hints may be ignored or restricted by some resolvers.
  • Validation flags depend on resolver policy and upstream data.
  • Unicode hostnames require punycode form; direct Unicode labels are rejected.
  • Timeouts classify as failures and lower the percentage.
  • Multiple correct answers are combined and compared after sorting.
  • Only the selected resolvers affect the percentage; adding more changes comparability.

Edge cases & error sources

  • Non‑existent domains return status errors and no answer text.
  • Trailing dots are removed before querying to avoid mismatches.
  • Labels starting or ending with a dash are rejected during validation.
  • TXT data is unquoted for display; embedded quotes may alter appearance.
  • OPT records are ignored in parsing.
  • Empty or partial answers count as failures for majority comparison.
  • Retry counts of zero send only one attempt per resolver.
  • Very short timeouts increase aborts and reduce agreement.
  • Client subnet strings that resolvers reject will produce failures.
  • Mixed IPv4 and IPv6 answers appear as multiple values; order is normalized.
  • Resolvers that omit the authenticated flag show an unknown state.
  • Network throttling and device sleep can skew measured timings.

Scientific & standards backing

Behavior aligns with IETF specifications for the Domain Name System, DNS integrity extensions, and client subnet signaling. Resolver policies vary by operator.

Privacy & compliance

Requests are issued from the browser directly to chosen public resolvers over HTTPS. No data is transmitted or stored server‑side by this page.

Step‑by‑Step Guide:

Domain name propagation is summarized as a percentage of resolvers that agree on the same answer.

  1. Enter a fully qualified domain example.com.
  2. Choose a record type A, AAAA, MX, etc..
  3. Optionally enable integrity checking AD flag insight.
  4. Optionally add a client subnet hint CIDR format.
  5. Adjust timeout and retries if needed.
  6. Select one or more resolvers to query.
  7. Run the check and review the summary and table.
Example: You request an A record for a new address. Six of seven selected resolvers agree, so the summary reports 86 % and lists the majority answer.
  • Copy the table as CSV for quick sharing.
  • Copy or download the JSON payload to archive inputs and results.
Pro tip: keep the resolver set constant across runs so percentages remain comparable.

FAQ:

Is my data stored?

No. Queries go from your browser to the resolvers you select, and the page does not keep records server‑side.

How accurate is the percentage?

It reflects only the selected resolvers at the time of the check. It is a helpful proxy for readiness, not a guarantee of universal visibility.

What units and formats are shown?

Percent is an integer. Time is in milliseconds. TTL values are seconds. You can copy a CSV table and a JSON payload of inputs, stats, and results.

Can I use it offline?

No. It needs network access to contact public resolvers and gather answers.

What does the AD mark mean?

It indicates that a resolver reports an authenticated answer. If absent or disabled, the state is unknown for that resolver.

Why do I see multiple answers?

Some records legitimately have several values or vary by network. The checker normalizes and compares them to decide the majority string.

How do I check only one resolver?

Clear the selection, pick the single resolver you want, then run the check to see its answer and timing alone.

What about cost or licensing?

Terms depend on how this page is distributed. Consult the surrounding site or package notes for licensing details.

Troubleshooting:

  • “Enter a valid domain” appears: ensure two or more labels and valid characters.
  • No results: select at least one resolver before checking.
  • Low percentage after a change: wait for TTLs to expire and retry.
  • Many timeouts: increase the timeout or reduce concurrent resolvers.
  • Client subnet rejected: verify CIDR format and try a broader prefix.
  • Integrity state always unknown: the resolver may not report it for this zone.

Glossary:

Domain Name System (DNS)
Hierarchical naming system that maps hostnames to records.
Resource Record (RR)
A typed answer such as A, AAAA, MX, or TXT.
Time to Live (TTL)
Lifetime in seconds that an answer may be cached.
Authenticated Data (AD)
Flag indicating that validation succeeded at the resolver.
Client Subnet (ECS)
Optional hint allowing location‑aware answers.
Propagation
Spread of updated records across resolvers over time.
Resolver
Service that answers queries by returning records for a name.
Majority answer
The normalized answer string seen most often across resolvers.