🌐 DNS Propagation Checker - Global DNS Check

🖧
The selected healthy worker peer will originate this network request.

🌍 Domain Configuration

Enter the domain name to check DNS propagation

🔍 Propagation Check

Checking DNS servers...
⚠️

Check Failed

📊 Propagation Summary

Domain:

{{ results.domain }} ({{ results.record_type }})

Check Time:

{{ results.total_time }}ms

Propagated Servers:

{{ results.summary.propagated_servers }}/{{ results.summary.total_servers }}

Propagation:

{{ results.summary.propagation_percentage }}% ({{ getPropagationStatusText(results.summary.propagation_status) }})

Found Records:
{{ record }}

🌐 DNS Server Results

{{ server.server_name }} ({{ server.server_ip }}) {{ getStatusText(server.status) }}
{{ record }}
No records found
{{ server.response_time }}ms

⚠️ Important Information

  • • {{ warning }}

No propagation check results yet

Enter a domain name and click"Check Propagation" to analyze DNS record propagation.

⚠️

ℹ️ About DNS Propagation Checker

DNS propagation checks and resolver caching

DNS propagation is the visible rollout of a DNS record change as recursive resolvers around the world stop using cached answers and query the authoritative name servers again. This global DNS checker compares answers from multiple resolvers so you can see whether a new A, AAAA, CNAME, MX, NS, TXT, SOA, or PTR record is already visible outside your own network.

What the checker is useful for

  • Website launches: confirm that a new A or AAAA record is resolving before changing traffic.
  • Email migrations: verify MX and TXT changes for mail routing, SPF, DKIM, and DMARC rollouts.
  • CDN and hosting moves: compare CNAME answers when a domain points to a new edge network.
  • Nameserver changes: check NS and SOA answers after a registrar or DNS provider migration.
  • Incident response: spot stale resolver caches when users in one region still reach an old endpoint.

Examples to check

Address and alias records

  • example.com A returns IPv4 addresses such as 203.0.113.10.
  • example.com AAAA returns IPv6 addresses for dual-stack hosting.
  • www.example.com CNAME shows the canonical host used by a CDN or platform.
  • 10.113.0.203.in-addr.arpa PTR checks reverse DNS for an address.

Mail and zone records

  • example.com MX lists mail exchangers and their preference values.
  • example.com TXT exposes SPF, DKIM selectors, DMARC, and verification strings.
  • example.com NS shows the delegated authoritative name servers.
  • example.com SOA shows zone authority data, including serial and timing fields.

Why different DNS servers disagree

Recursive resolvers cache positive DNS answers for the record's TTL, and negative answers can also be cached from SOA data. A resolver that queried the old record seconds before your update may continue returning it until that cache entry expires, while another resolver that had no cached entry may show the new value immediately. Parent-zone delegation, registrar updates, DNSSEC validation failures, split-horizon DNS, and resolver-specific filtering can also make propagation results differ by network.

How to read propagation results

  • Consistent new answers usually mean the change is visible from the sampled resolvers.
  • Mixed old and new answers usually point to normal TTL-based cache expiry during a migration.
  • NXDOMAIN or no data may mean the record is missing, the zone is not delegated, or a negative cache is still active.
  • Unexpected CNAME chains can reveal an incomplete CDN, SaaS, or hosting-platform change.
  • Different TXT values are common during email-authentication changes; wait for caches before removing old values.

Caching limits and rollout tips

  • Lower TTL before planned changes: reduce the existing TTL at least one old TTL period before migration.
  • Do not expect instant global results: resolvers are allowed to use cached data until TTL expiry.
  • Check authoritative DNS too: propagation checks are resolver samples, not proof that every resolver on the internet agrees.
  • Flush local cache carefully: your browser, OS, router, VPN, and ISP resolver can each cache answers.
  • Keep old infrastructure alive: leave previous web or mail targets active until old DNS answers age out.

Standards and source references

DNS naming, delegation, and resolver behavior are defined by RFC 1034 and the DNS message and record format by RFC 1035. TTL and authoritative-answer clarifications are covered in RFC 2181, negative caching behavior in RFC 2308, and record type assignments in the IANA DNS Parameters registry.

API Usage Example:

POST /api/tools/network/dns-propagation
Content-Type: application/json

{
    "domain": "example.com",
    "record_type": "A"
}
Ready