DNS Propagation
free/v1/dns/propagationTests DNS propagation by querying multiple major public DNS resolvers simultaneously. Compares responses to identify propagation delays, inconsistencies, or caching issues. Uses a 60-second cache to detect real-time propagation changes. Pro tip: Lower your TTL to 300 seconds at least 48 hours before making DNS changes for faster propagation.
What It Does
Queries the specified DNS record from 8 major public DNS resolvers in parallel — Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9), OpenDNS (208.67.222.222), AdGuard, DNS.SB, Mullvad, and NextDNS — and compares results. Reports propagation status (complete, partial, none), identifies inconsistent responses, and calculates propagation percentage. Classifies the result as `aligned`, `propagating`, `geo_distributed`, or `inconsistent` so users can distinguish stale-cache lag from intentional geo-load balancing (e.g. Azure Traffic Manager, AWS Route 53 latency routing).
Why It's Useful
After DNS changes, propagation can take hours to complete globally. Some ISP resolvers cache aggressively beyond the TTL value (RFC 2308). This endpoint tests against 8 major public resolvers across multiple regions that correctly honor TTL, giving you a reliable propagation baseline to verify changes and troubleshoot DNS-related user reports.
Use Cases
Post-Change Verification
After updating DNS records, verify changes have propagated before announcing a deployment as complete.
Confirm DNS propagation across 8 major public resolver networks (serving billions of users) before announcing deployment completion.
Incident Response
Users in certain regions report connection issues. Check if DNS is consistent across resolvers.
Quickly diagnose regional DNS inconsistencies during outages.
Migration Monitoring
During DNS migration, continuously monitor propagation to all major resolvers.
Track migration progress with real-time propagation visibility.
Parameters
| Name | Type | Required | Description |
|---|---|---|---|
domain | string | Required | The domain to check propagation forExample: example.com |
type | string | Optional | DNS record type to check. Defaults to A.Example: AOptions: A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, CAA, PTR, DNSKEY, DS, TLSA, NAPTR, SSHFP, HTTPS, SVCB, DNAME, LOC, URI, CERT, SMIMEA |
Response Fields
| Field | Type | Description |
|---|---|---|
domain | string | The queried domain |
record_type | string | The DNS record type checked |
propagation_status | string | complete (all responding resolvers agree, OR geo-DNS detected and working as intended), partial, or none |
consistent | boolean | Whether all responding resolvers return the same records (true also for `geo_distributed` dispersion — every resolver is correctly answering for its vantage point) |
resolvers | array | Per-resolver result with name, region, status (consistent | differs | error), records, dnssec_validated, duration_ms, error, error_type, and divergence_reason (geo_dns | lag | null) |
summary.total_resolvers | number | Number of resolvers queried (currently 8) |
summary.responding | number | Resolvers that returned a successful response (no error/timeout) |
summary.consistent_count | number | Resolvers whose records match the consensus (or, for `geo_distributed`, all responding resolvers) |
summary.propagation_percentage | number | consistent_count / responding × 100, rounded |
summary.expected_records | array | Flat list of expected record values (majority set, or union across sets when geo-DNS is detected) |
summary.expected_records_by_set | array | Every distinct record set seen, sorted by frequency descending. One element for `aligned`, multiple for `geo_distributed` showing the per-region picture |
summary.dispersion | string | Why resolvers disagree (or don't): `aligned` (all match), `propagating` (clear majority + minority on a high-TTL zone — classic stale-cache lag), `geo_distributed` (multiple distinct answers — load balancer working as designed), `inconsistent` (genuinely uncertain) |
summary.min_ttl | number | Lowest TTL across responding resolvers (or null if no records) |
summary.max_ttl | number | Highest TTL across responding resolvers (or null if no records) |
Code Examples
curl "https://api.edgedns.dev/v1/dns/propagation" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d "domain=example.com"const response = await fetch(
'https://api.edgedns.dev/v1/dns/propagation?domain=example.com',
{
headers: {
'Authorization': 'Bearer YOUR_API_KEY'
}
}
);
const data = await response.json();
console.log(data);import requests
response = requests.get(
'https://api.edgedns.dev/v1/dns/propagation',
headers={'Authorization': 'Bearer YOUR_API_KEY'},
params={
'domain': 'example.com'
}
)
data = response.json()
print(data)Read the full DNS Propagation guide
Why it matters, real-world use cases, parameters, response fields, and how to call it from Claude, ChatGPT, or Gemini via MCP.
Read the guide →Related Endpoints
External References
Learn more about the standards and protocols behind this endpoint.
Try This Endpoint
Test the DNS Propagation endpoint live in the playground.