DNS is one of those infrastructure concerns that works invisibly until it doesn't, and then becomes the source of incidents that look like "everything is broken." Picking the right DNS strategy is more than just "use Route 53" — it shapes failover, latency, and cost in ways that compound over time.
This post is the DNS decisions that production systems care about: routing strategies, failover patterns, and the cost surprises that come from getting it wrong.
What DNS Actually Does for You
Beyond "name to IP," modern cloud DNS handles:
- Routing decisions. Different IPs for different users based on geography, latency, or weights.
- Health checks. Routing around unhealthy endpoints.
- Failover. Pointing at a secondary region when the primary is down.
- Service discovery. Internal DNS for service-to-service communication.
A "DNS strategy" is really a strategy for all of these.
The Major Providers
Route 53 (AWS). Mature, deeply integrated with AWS, expensive at scale.
Cloud DNS (GCP). Solid, well-priced.
Azure DNS. Functional, less polished than Route 53.
Cloudflare DNS. Often paired with Cloudflare's CDN and security features. Strong free tier.
NS1. Multi-cloud, advanced traffic management features. Premium pricing.
DNSimple, easyDNS, etc. Smaller players, often fine for non-complex needs.
For most teams: stay with your primary cloud's DNS for the basics. Add Cloudflare or similar at the edge if you need their CDN/security features.
Routing Strategies
The interesting DNS features start with routing.
Simple. One DNS record, one answer. Just resolves to an IP.
Weighted. Multiple records with weights. 90% of queries get IP A, 10% get IP B. Useful for canary deployments.
Latency-based. Returns the IP geographically closest (by latency) to the resolver. Common for multi-region setups.
Geographic. Returns based on the resolver's location (country, continent). Used for compliance ("EU users to EU endpoints") and content localization.
Failover. Primary endpoint is used while healthy; falls back to secondary if the primary fails health checks.
Multivalue. Returns multiple healthy IPs; the client picks one. Cheap load balancing.
Each cloud provider has its own variations and capabilities. Route 53 has the broadest set; others have most of these.
Failover Patterns
For multi-region disaster recovery, DNS failover is one of the most common patterns.
Primary record (us-east-1):
Type: A
Set ID: primary
Failover: PRIMARY
Health check: linked to us-east-1 endpoint
Value: 1.2.3.4
Secondary record (us-west-2):
Type: A
Set ID: secondary
Failover: SECONDARY
Value: 5.6.7.8
When the health check for the primary fails, DNS starts returning the secondary IP.
The catch: DNS has TTLs. Clients cache the resolved IP for the TTL duration. A TTL of 60 seconds means up to 60 seconds of failover delay; a TTL of 5 minutes means up to 5 minutes.
For failover-critical systems, set TTL to 30-60 seconds. Lower means more DNS queries (more cost); higher means slower failover.
Health Checks
DNS health checks decide whether an endpoint is healthy. They are not a substitute for application health monitoring — they exist solely to make routing decisions.
Common patterns:
- HTTP/HTTPS GET to a health endpoint
- TCP connect to a port
- String matching in the response body
Health checks have their own properties:
- Frequency (every 10s, 30s, etc.)
- Threshold (how many consecutive failures before marking unhealthy)
- Regions (Route 53 can check from multiple regions; majority decides)
The threshold setting matters more than people realize. Too low and you flap on transient failures; too high and failover takes minutes longer than necessary.
A reasonable default: 3 consecutive failures at 10-second intervals = unhealthy. Marks unhealthy in about 30 seconds.
TTL Strategy
Different records benefit from different TTLs:
- Static services (CDN, marketing site): 1+ hour TTL. Cheap to query, slow to change.
- Production endpoints with possible failover: 60 seconds. Fast failover, more queries.
- CNAMEs for migrations: 60-300 seconds during migration, longer once stable.
- Reverse lookups, MX, etc.: hours. Rarely change.
There is a cost trade-off. Shorter TTLs = more queries = higher DNS bill. For most production records, the cost is negligible. For services with billions of queries per day, it adds up.
Anycast and Geographic Distribution
Most managed DNS uses anycast: the DNS servers advertise the same IPs from many locations worldwide. A query is answered by the closest one.
The benefit: low latency for DNS resolution everywhere. The implication: DNS is rarely the latency bottleneck, even for global applications.
For DNS for an internal service that does not need global reach, you can use simpler DNS (a couple of resolvers in one region). For public-facing services, anycast is standard.
Cost Considerations
DNS costs scale with queries. Typical pricing:
- Route 53: $0.50 per million queries, plus $0.50 per hosted zone per month.
- Cloud DNS: $0.40 per million queries.
- Cloudflare: Free for basic; paid plans for advanced features.
For most workloads, DNS cost is a small line item. For very high-volume APIs (billions of queries per month), it becomes meaningful. A 100 million queries/month service costs ~$50; a 10 billion queries service costs $5,000.
The most common cost surprise: a misconfigured client that queries DNS repeatedly instead of caching. Mobile apps that disable DNS caching, applications that resolve on every request, etc. Watch DNS query patterns alongside cost.
Internal DNS
For service-to-service communication inside a network or cluster:
- Kubernetes: CoreDNS resolves
<service>.<namespace>.svc.cluster.localto service IPs. - AWS: Route 53 Private Hosted Zones for VPC-internal resolution.
- GCP: Cloud DNS Private Zones.
- Consul: Service discovery with DNS interface.
For Kubernetes, the built-in DNS is sufficient for most needs. For multi-cluster or non-K8s services, you may need additional internal DNS.
DNS as an Outage Vector
DNS configuration errors cause some of the most painful outages. Common scenarios:
- A bad config push removes a critical record
- Health checks misconfigured, marking healthy endpoints unhealthy
- TTL set too long, slowing recovery
- Apex records pointing to old, no-longer-resolving endpoints
The protective patterns:
- DNS changes through git + CI (not click-ops in the console)
- Test DNS changes in non-production zones first
- Monitor DNS resolution time and success rates
- Have a runbook for DNS rollback
A bad DNS change at 4 PM Friday becomes a weekend incident.
Common Mistakes
- TTL too short on stable records. A 30-second TTL on the marketing site burns money.
- TTL too long on failover records. Minutes of downtime that should have been seconds.
- Single-point-of-failure DNS. All records on one provider's failure = global outage.
- No internal DNS strategy. Services hardcoding internal IPs.
- DNS records for resources that should be load-balanced. A separate A record per node defeats DNS-level abstraction.
A Practical Setup
For a typical SaaS in AWS:
- Public DNS: Route 53 for the main domain. Latency-based routing if multi-region. 60s TTL on production endpoints; longer for static.
- Internal DNS: Private Hosted Zones for VPC-internal services. Kubernetes CoreDNS for in-cluster.
- Edge: Cloudflare in front for CDN, WAF, and DDoS protection. The Cloudflare DNS serves the apex; Route 53 handles internal/region-specific routing.
- Health checks: Route 53 health checks for failover decisions. Synthetic monitoring for the application layer.
- Changes: Through Terraform, reviewed via PR.
This setup handles the typical needs: low-latency global resolution, fast failover, cost-controlled, change-controlled.
The Boring Reality
DNS works. The interesting decisions are about how much sophistication is worth the cost.
For most workloads: a single provider's DNS, sensible TTLs, basic health checks. Boring, reliable, cheap.
For multi-region or compliance scenarios: more routing logic, more thought on TTLs and health checks.
For high-volume APIs: cost optimization through TTL tuning and query patterns.
DNS rarely needs to be exotic. Most teams should aim for "DNS that works invisibly" rather than "DNS as differentiator."
Designing DNS for a new system or evaluating whether your current setup has cost or reliability surprises waiting? We help teams pick DNS strategies that match their failure modes. scopeforged.com