The DNS service decides what's possible
The "DNS service" was a commodity for years. In 2026 it's a meaningful product decision — different services give you different capabilities (geo-routing, traffic shaping, attack mitigation, programmable behaviour). Below is what to weigh.The big picks
- Cloudflare DNS — the practical default in 2026. Free tier covers most personal / small-business needs. CNAME flattening at apex. Integrated with Cloudflare's broader security and CDN features.
- AWS Route 53 — deep AWS integration, alias records to AWS resources, geo / latency / weighted routing. Default if you're heavy on AWS.
- NS1 — programmable / API-first, advanced traffic steering, popular with infra-heavy organisations.
- BunnyDNS — competitive pricing, geo-routing, integrated with their CDN.
- Hurricane Electric DNS (free) — venerable, free tier, useful as a secondary.
- Self-hosted (PowerDNS, BIND, Knot) — for organisations that need full control.
Decision dimensions
- Apex aliasing — does it work for your CDN/load balancer setup?
- Geo / latency routing — for global apps, often essential
- API quality — for IaC integration
- Failover / health checks — does the service do active health checking and route accordingly?
- DDoS resilience — large DNS providers absorb DDoS better than self-hosted
- DNSSEC support — table stakes; verify
- Pricing model — per-zone, per-query, or flat?
- Privacy / data residency — relevant for some regulated industries
Cloudflare in detail
- Free tier covers unlimited DNS queries, basic DDoS protection, free SSL
- CNAME flattening / "linked" records work well at apex
- Anycast network — fast lookups globally
- Argo Tunnel / Cloudflare Tunnel for connecting origins without exposing IP
- Workers + DNS for programmable routing
The downside: deep dependency on a single vendor. If you lean on Cloudflare's CDN + DNS + security, switching becomes its own project.
Route 53 in detail
- Pay-per-zone + per-query (cheap, but can add up at scale)
- Alias records to AWS resources (ALB, CloudFront, S3) — handle apex routing cleanly
- Health checks + DNS failover
- Geo-routing, latency-based routing, weighted routing
- Tight integration with AWS IAM, CloudWatch, Route 53 Resolver
Where it shines: AWS-resident architectures. Where it doesn't: cross-cloud or non-AWS-heavy deployments.
Multi-provider DNS
For high-criticality services, run DNS across multiple providers:- Primary on Cloudflare, secondary on Route 53 (or vice versa)
- Both providers configured as authoritative
- Use a sync mechanism (octoDNS, dnscontrol, or vendor-specific replication)
- Cost: multi-provider overhead, but resilience to a single provider outage
The 2016 Dyn outage taught the industry this lesson. Big DNS providers have outages; multi-provider is the architectural mitigation.
The thing nobody tests
What happens when your DNS provider has a multi-hour outage? Most teams don't have a documented answer. The exercise:- Document where DNS authority is configured (the registrar's NS records)
- Document a switch-to-secondary procedure
- Test it. Quarterly.
Self-hosted: when it makes sense
- Internal DNS for a corporate network (almost always self-hosted on AD or similar)
- Specialist routing requirements that managed providers don't support
- Compliance / data sovereignty requirements that exclude commercial providers
For external authoritative DNS on a public service, self-hosted is rarely the right answer in 2026 — the operational overhead exceeds the cost difference.
One pattern we'd warn about
Single-provider DNS for a service that pays you. The provider WILL have an outage at some point. The cost of multi-provider DNS is small; the cost of a 6-hour DNS outage is large.One pattern that always pays off
Lower-TTL drills. Once a quarter, lower the TTL on a specific record to 60s, change it, observe propagation, change it back, raise the TTL. Builds the muscle memory for an emergency.What's your DNS architecture? And — for the multi-provider folks — has the synchronisation overhead been worth it for the resilience you've gained?
