A DNS resolution failure means the source's webhook system tried to look up your endpoint's hostname, got no usable answer, and gave up before even attempting the HTTP request. The provider's dashboard usually shows "DNS lookup failed" or "NXDOMAIN" rather than an HTTP status code — the request never made it to TLS.
Root Causes
1. The domain expired or was deleted
The domain you registered the webhook URL on expired or got deleted. Cheap domains forget about renewal email reminders. Check the domain's WHOIS / RDAP record. dig your-domain.com from a public resolver — if you get NXDOMAIN, the domain itself is the problem.
2. DNS record was changed and hasn't propagated
You changed the A or AAAA record (moving infrastructure, switching cloud providers). The change has to propagate to the source's DNS resolver. Cloudflare, AWS Route53, and Google Cloud DNS all have low TTLs (60s-300s typical), so propagation is fast. But the source's resolver may cache for longer than your TTL — most cache-busting takes 5-15 minutes.
3. Missing AAAA record on an IPv6-only network
Some webhook senders run from IPv6-only networks (rare but increasing). If your domain has only an A record (IPv4) and no AAAA (IPv6), the source can't connect. Add both A and AAAA records.
4. DNSSEC misconfiguration
You enabled DNSSEC on your domain but a key rotation went wrong, leaving signatures invalid. Resolvers that validate DNSSEC return SERVFAIL. Most webhook senders don't validate DNSSEC, so this only breaks for the strict ones — but those are increasing. Validate with dig +dnssec.
5. Wildcard CNAME loops or self-references
Your DNS has *.example.com CNAME example.com with no terminal A record. Some resolvers cope; others time out. Make sure every CNAME chain terminates at an A or AAAA record.
Fix It — Diagnostic Sequence
# 1. Confirm DNS exists and is correct
dig +short A your-webhook-host.example.com
dig +short AAAA your-webhook-host.example.com
# 2. Check from multiple resolvers (provider may use different DNS)
dig @8.8.8.8 your-webhook-host.example.com # Google
dig @1.1.1.1 your-webhook-host.example.com # Cloudflare
dig @9.9.9.9 your-webhook-host.example.com # Quad9
# 3. Check propagation (after a change)
dig +trace your-webhook-host.example.com
# 4. Validate DNSSEC if enabled
dig +dnssec your-webhook-host.example.comProvider-Side Caching
- Stripe: caches DNS for 5 minutes; honors TTL ≥60s. Failed deliveries due to DNS issues retry on the standard 3-day schedule.
- GitHub: less documented, but in practice respects TTLs. Test deliveries from the GitHub UI re-resolve every time.
- Shopify: caches more aggressively; DNS changes can take 10-30 minutes to fully propagate to Shopify's resolvers.
Prevention
- Set DNS TTL to 300s or less on records that change. Lower TTL = faster propagation when you fix something.
- Auto-renew domains. Charge to a credit card that won't expire mid-renewal-cycle.
- Monitor DNS uptime — services like UptimeRobot or DNS Spy alert when records go missing.
- Don't host the webhook URL on a critical-but-fragile domain. Use a stable subdomain on a domain you'll keep for years.
How to Reproduce
Edit /etc/hosts on your dev machine to point your webhook host at 0.0.0.0. Curl the URL — you'll get connection refused. Restore the host. Then try a deliberately misspelled domain (typo-domain.example.com) and watch the DNS error from your resolver.
Frequently Asked Questions
How long until DNS propagation is guaranteed?
There's no guarantee — the answer depends on every cache between you and the source. Practically, 90% of resolvers see new records within 5-15 minutes for low-TTL records. Plan for a 1-hour propagation window for critical changes.
My domain works fine for browsers but webhooks fail. Why?
Likely an IPv6-only AAAA record where the source resolves IPv6 first. Try `curl -6` on the URL from a known-IPv6 host. Or the source's resolver is using a stale cache from before your DNS change.
Should I switch DNS providers if I'm seeing failures?
Probably not — most managed DNS providers have similar reliability. Verify the failure is actually DNS (not network or TLS) before switching.