DNS
Domain Name System - records, zones, TTL, anycast, propagation, and modern managed DNS providers
DNS
DNS turns names humans use (api.example.com) into addresses machines use (93.184.216.34, 2606:2800:220:1:248:1893:25c8:1946). It's also the original distributed database — older than the web, still surprisingly central to every system that uses the internet.
What You Actually Care About
| Concept | Why it matters |
|---|---|
| Records (A, AAAA, CNAME, MX, TXT...) | The atoms of DNS — different record types for different purposes |
| Zones | A delegated namespace you own (e.g. example.com) |
| TTL | How long resolvers cache an answer; controls propagation time |
| Authoritative vs Recursive | Authoritative servers know the answer; recursive servers ask around and cache |
| Anycast | Same IP, many locations — nearest one answers |
| DNSSEC | Cryptographic signatures so resolvers can verify answers |
The Two Halves of DNS
┌────────────────────────────┐
│ Your application │
│ resolves "example.com" │
└────────────┬───────────────┘
│
▼
┌────────────────────────────┐
│ Recursive resolver │ (8.8.8.8, 1.1.1.1, your ISP)
│ asks around, caches │
└────────────┬───────────────┘
│
┌───────────┴────────────┐
▼ ▼
┌──────────┐ ┌──────────────┐
│ Root │ ←───── │ Authoritative│
│ / TLD │ delegates │ for example │
└──────────┘ └──────────────┘- Authoritative DNS — what you configure for your domain. Cloudflare, Route 53, NS1, etc. answer queries about
example.com. - Recursive DNS — what your laptop, phone, server uses to resolve names. 1.1.1.1, 8.8.8.8, your ISP's resolver.
Most "DNS" decisions are about the authoritative side: which provider, what records, what TTLs, what failover.
The Players
| Provider | Notes |
|---|---|
| Cloudflare DNS | Anycast, fast, free tier; integrated with their CDN/WAF |
| AWS Route 53 | Reliable, deeply tied to AWS, geo + latency-based routing |
| NS1 (IBM) | Advanced traffic management, healthchecks, GSLB |
| Google Cloud DNS | Solid, integrated with GCP, less feature-rich than competitors |
| Azure DNS | Same story for Azure |
| DNSimple, DNSMadeEasy | Smaller, developer-friendly, simple pricing |
| Self-hosted BIND / PowerDNS / Knot | When you must, but rarely the right call for public DNS |
For most teams: Cloudflare DNS (especially if you already use them for CDN) or Route 53 (if you're already in AWS). Avoid running your own authoritative DNS for the public internet unless you have a very specific reason.
Learning Path
1. Getting Started
Register a domain, set up authoritative DNS, add basic records, dig into answers
2. Records & Zones
A/AAAA/CNAME/MX/TXT/SRV/CAA, apex CNAME flattening, delegation, DNSSEC
3. Best Practices
TTL strategy, redundancy, monitoring, DDoS protection, common pitfalls
TTL: The One Knob You'll Actually Tune
Every DNS record has a TTL — how long recursive resolvers may cache it. Trade-offs:
| TTL | Effect |
|---|---|
| 300s (5 min) | Fast failover; more query volume to authoritative |
| 3600s (1 hour) | Balanced default for most records |
| 86400s (1 day) | Cheap; failover and re-IP changes propagate slowly |
| 5s | Effectively always asks; only for active failover scenarios |
Default to 5 min for records that may change, 1 hour for stable ones. The moment you set a 24h TTL, you've signed up for 24h of downtime if that record needs to change in an emergency.
When planning a change: lower the TTL days before, then make the change, then raise the TTL back up.
Things DNS Is and Isn't For
| It is | It isn't |
|---|---|
| Mapping names to addresses | A load balancer (it can do crude balancing; not your real LB) |
| Domain verification (TXT records) | A configuration store (don't put dynamic data in DNS) |
| Mail routing (MX records) | A secret store |
| Service discovery (SRV records) | Hot-reload config (TTL minimum) |
| Failover hinting | Real-time traffic control |
DNS-based load balancing exists (round-robin, geo, latency, weighted). It's coarse and slow. For real load balancing, use a load balancer. DNS hands you to one of N IPs; from then on, the connection is on its own.
DNS misconfiguration is a leading cause of outages. A bad NS record can take you offline for hours while caches expire. Test changes in a staging zone. Lower TTLs before changes. Never delete records you're not 100% sure about.