DNS is the first point of failure for every internet-facing application. A misconfigured DNS record causes total outage for all users. This guide covers DNS architecture for cloud infrastructure including health-check failover, geographic routing, DNSSEC for security, and choosing between Cloudflare DNS, AWS Route53, and self-hosted solutions.
The 2025 Catchpoint Internet Performance Report found that DNS resolution adds an average of 20-80ms to every request. Poorly configured DNS adds 200ms+ due to unnecessary CNAME chains, high TTLs preventing failover, or missing geographic routing. DNS-related outages account for 14% of all publicly reported cloud service disruptions.
---
DNS Record Types for Cloud Infrastructure
| Record Type | Purpose | Example | TTL Recommendation |
| A | IPv4 address | app.example.com -> 93.184.216.34 | 300s (failover) or 3600s (stable) |
| AAAA | IPv6 address | app.example.com -> 2001:db8::1 | Same as A record |
| CNAME | Alias to another domain | www -> app.example.com | 3600s |
| MX | Mail server | example.com -> mail.example.com | 3600s |
| TXT | Verification, SPF, DKIM | example.com -> "v=spf1..." | 3600s |
| SRV | Service discovery | _http._tcp -> app:443 | 300s |
| CAA | Certificate authority auth | example.com -> letsencrypt.org | 3600s |
<h1>Verify DNS resolution</h1>
dig +short app.example.com A
dig +short app.example.com AAAA
<h1>Check full DNS chain</h1>
dig +trace app.example.com
<h1>Query specific nameserver</h1>
dig @8.8.8.8 app.example.com A
<h1>Check all record types</h1>
dig app.example.com ANY
---
Health-Check Failover
DNS failover automatically removes unhealthy endpoints from DNS responses. The DNS provider sends health check requests to each endpoint and only returns healthy IPs.
Cloudflare Health Checks
<h1>Create a health check via Cloudflare API</h1>
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/healthchecks" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
-d '{
"name": "primary-origin",
"address": "origin1.example.com",
"type": "HTTPS",
"check_regions": ["WNAM", "ENAM", "WEU"],
"http_config": {
"method": "GET",
"path": "/api/health",
"port": 443,
"expected_codes": "200"
},
"interval": 60,
"retries": 2,
"timeout": 5
}'
Route53 Health Checks
<h1>AWS Route53 health check</h1>
aws route53 create-health-check \
--caller-reference "primary-$(date +%s)" \
--health-check-config '{
"IPAddress": "93.184.216.34",
"Port": 443,
"Type": "HTTPS",
"ResourcePath": "/api/health",
"RequestInterval": 30,
"FailureThreshold": 3
}'
| Parameter | Recommended Value | Why |
| Check interval | 30-60 seconds | Balance between detection speed and cost |
| Failure threshold | 2-3 failures | Prevents false positives from transient issues |
| Timeout | 5 seconds | Shorter than check interval |
| Check regions | 3+ regions | Prevents single-region false positives |
| Health endpoint | /api/health | Dedicated endpoint with DB connectivity check |
---
GeoDNS (Geographic Routing)
GeoDNS routes users to the nearest server based on the resolver IP geolocation. This reduces latency by 40-120ms for globally distributed applications.
<h1>Route53 geolocation routing policy</h1>
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890 \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "us-east",
"GeoLocation": {"ContinentCode": "NA"},
"TTL": 300,
"ResourceRecords": [{"Value": "10.0.1.1"}]
}
}, {
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "eu-west",
"GeoLocation": {"ContinentCode": "EU"},
"TTL": 300,
"ResourceRecords": [{"Value": "10.0.2.1"}]
}
}]
}'
---
DNSSEC Implementation
DNSSEC cryptographically signs DNS responses, preventing cache poisoning and man-in-the-middle attacks. Without DNSSEC, an attacker can forge DNS responses and redirect users to malicious servers.
<h1>Check if a domain has DNSSEC enabled</h1>
dig +dnssec example.com A
<h1>Verify DNSSEC chain of trust</h1>
delv @8.8.8.8 example.com A +vtrace
<h1>Cloudflare: Enable DNSSEC via API</h1>
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/dnssec" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
-d '{"status": "active"}'
---
Provider Comparison
| Feature | Cloudflare DNS | AWS Route53 | Self-Hosted (BIND/PowerDNS) |
| Price | Free (basic) | $0.50/zone + $0.40/M queries | Server cost only |
| Anycast | Yes (300+ PoPs) | Yes (global) | DIY (complex) |
| Health checks | Free (basic) | $0.50/check/month | Manual scripting |
| GeoDNS | Enterprise plan | Included | PowerDNS GeoIP backend |
| DNSSEC | One-click | Supported | Manual key management |
| API | REST + Terraform | REST + Terraform + CLI | API depends on software |
| SLA | 100% (Enterprise) | 100% | Self-managed |
| DNS propagation | Under 5 seconds | 60 seconds | Depends on TTL |
For CDN configuration that works alongside your DNS setup, see our CDN configuration best practices guide. Teams automating SSL certificates should read our SSL/TLS certificate management guide. For a complete infrastructure networking overview, check our Kubernetes networking basics guide.
---
Frequently Asked Questions
What TTL should I set for production DNS records?
For records behind a load balancer or CDN (stable endpoints), use 3600 seconds (1 hour). For records that participate in failover, use 60-300 seconds. Lower TTLs mean faster failover but higher query volume to your DNS provider. Never set TTLs below 30 seconds as many recursive resolvers ignore very low TTLs.
How long does DNS propagation actually take?
DNS does not "propagate" in the traditional sense. When you change a record, the old record remains cached at recursive resolvers until its TTL expires. If your old TTL was 3600 seconds, it takes up to 1 hour for all resolvers to pick up the change. Before making critical changes, lower the TTL to 60 seconds 24 hours in advance, make the change, then raise the TTL back.
Should I use CNAME or A records for cloud services?
Use CNAME records when pointing to cloud provider endpoints (load balancers, CDNs) because their IP addresses can change. Use A records only when you control the IP address directly. Exception: the zone apex (example.com without www) cannot have a CNAME per the DNS standard. Use ALIAS records (Route53) or CNAME flattening (Cloudflare) for the apex.
Is DNSSEC worth the operational overhead?
Yes, especially for applications handling financial data, authentication, or sensitive information. Modern DNS providers (Cloudflare, Route53) make DNSSEC a one-click setup with automatic key rotation. The main risk is misconfigured key rollovers, which can cause total DNS failure. Use a provider with automatic key management rather than managing keys manually.
How do I test DNS failover before production?
Set up your failover configuration with health checks pointing to a test endpoint. Deliberately fail the health check by returning a 500 status code from the test endpoint. Verify that the DNS provider stops returning the unhealthy IP within your configured failure threshold (typically 90-180 seconds). Test the recovery path by restoring the health check and verifying the IP returns to rotation.