Skip to main content

DNS Propagation

free
GET/v1/dns/propagation

Tests 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

DevOps Engineer

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.

SRE

Incident Response

Users in certain regions report connection issues. Check if DNS is consistent across resolvers.

Quickly diagnose regional DNS inconsistencies during outages.

Infrastructure Engineer

Migration Monitoring

During DNS migration, continuously monitor propagation to all major resolvers.

Track migration progress with real-time propagation visibility.

Parameters

NameTypeRequiredDescription
domainstringRequiredThe domain to check propagation forExample: example.com
typestringOptionalDNS 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

FieldTypeDescription
domainstringThe queried domain
record_typestringThe DNS record type checked
propagation_statusstringcomplete (all responding resolvers agree, OR geo-DNS detected and working as intended), partial, or none
consistentbooleanWhether all responding resolvers return the same records (true also for `geo_distributed` dispersion — every resolver is correctly answering for its vantage point)
resolversarrayPer-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_resolversnumberNumber of resolvers queried (currently 8)
summary.respondingnumberResolvers that returned a successful response (no error/timeout)
summary.consistent_countnumberResolvers whose records match the consensus (or, for `geo_distributed`, all responding resolvers)
summary.propagation_percentagenumberconsistent_count / responding × 100, rounded
summary.expected_recordsarrayFlat list of expected record values (majority set, or union across sets when geo-DNS is detected)
summary.expected_records_by_setarrayEvery distinct record set seen, sorted by frequency descending. One element for `aligned`, multiple for `geo_distributed` showing the per-region picture
summary.dispersionstringWhy 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_ttlnumberLowest TTL across responding resolvers (or null if no records)
summary.max_ttlnumberHighest TTL across responding resolvers (or null if no records)

Code Examples

cURL
curl "https://api.edgedns.dev/v1/dns/propagation" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d "domain=example.com"
JavaScript
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);
Python
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.