DNS — Domain Name System
DNS is the phonebook of the internet. Humans remember example.com; routers need 93.184.216.34. DNS bridges this gap with a hierarchical, distributed, eventually-consistent database.
How it works
DNS is the phonebook of the internet. Humans remember example.com; routers need 93.184.216.34. DNS bridges this gap with a hierarchical, distributed, eventually-consistent database. It is also one of the most common single points of failure in real outages — if your DNS is down, no one can find you, no matter how healthy your servers are.
DNS resolution is a recursive walk. Your browser asks the operating system's stub resolver. The stub resolver asks a recursive resolver (often your ISP's, or 8.8.8.8 / 1.1.1.1). The recursive resolver asks the root nameserver, which points to the TLD nameserver for .com, which points to the authoritative nameserver for example.com, which returns the A record. Each step is cached aggressively with a TTL (time to live).
Short TTLs (60s) let you fail over quickly but increase DNS query load. Long TTLs (86400s) reduce load but mean a DNS change takes up to a day to propagate globally. Most production setups use 300-3600s as a compromise, then lower the TTL ahead of planned changes.
Common record types: A (IPv4 address), AAAA (IPv6), CNAME (alias to another domain), MX (mail server), TXT (arbitrary text — used for verification, SPF, DKIM), NS (delegation to another nameserver), SOA (start of authority — zone metadata). CNAMEs cannot coexist with other records on the same name, which is why root domains (the apex example.com) often use ALIAS or ANAME records instead.
You are planning a migration to a new origin IP next week. What should you do to your DNS TTL today?
Pick one answer.
Your DNS change has not propagated for some users 12 hours later. What could be wrong?
Pick one answer.
The full recursive walk, annotated. When your browser asks for www.example.com, the actual sequence is richer than 'ask root, ask TLD, ask authoritative.' A real lookup typically takes only one network round trip thanks to aggressive caching at every layer — but on a cold cache it walks the entire hierarchy.
The first query goes to the configured recursive resolver (e.g., 1.1.1.1 or 8.8.8.8). The resolver is a server run by your ISP, Cloudflare, Google, or your enterprise. It then walks: root nameservers (13 logical names, hundreds of anycast instances globally) → TLD nameserver for .com (operated by Verisign) → authoritative nameserver for example.com (operated by whoever you delegated to — Cloudflare, Route 53, etc.). The authoritative server returns the A record, and the resolver caches it for the duration of the TTL.
The recursive resolver does the entire walk so your laptop doesn't have to. This is a key scaling decision: caching is pushed as close to the user as possible (browser cache, OS stub resolver cache, recursive resolver cache, authoritative nameserver cache), with each layer serving cached answers until TTL expires.
TTL is a two-sided knob. The TTL you set on a record is a contract with every recursive resolver on the planet: 'you may cache this answer for N seconds.' Lower is not always better, and higher is not always better — the right value depends on what you're optimizing for.
| TTL | Failover speed | Query load on auth NS | Use case |
|---|---|---|---|
| 60s | sub-minute | very high (millions/sec globally) | active failover, blue-green deploys |
| 300s (5m) | 5 minutes | moderate | typical web app default |
| 3600s (1h) | 1 hour | low | stable records (MX, TXT for SPF) |
| 86400s (1d) | 1 day | minimal | apex A records that never change |
A common production pattern: keep your default TTL at 300s, then proactively lower it to 60s 3× your current TTL before any planned IP change. So if you're at 3600s today, drop to 600s a day before, then to 60s an hour before, then flip the record. This guarantees every resolver on the planet has the short TTL cached when you cut over.
A massive Mirai-botnet DDoS attack hit Dyn (a major DNS-as-a-service provider used by Twitter, Reddit, GitHub, Spotify, Netflix, and others). The attack flooded Dyn's authoritative nameservers with tens of millions of DNS queries per second from compromised IoT devices. Recursive resolvers couldn't reach Dyn, so they couldn't resolve domains like twitter.com — and the entire East Coast of the US effectively lost access to those services for several hours. The origin servers were healthy. The application servers were healthy. The CDN was healthy. Only DNS was down — and that was enough to take half the internet offline for users in the affected region. Lesson: DNS is a single point of failure for your domain. Use two DNS providers (e.g., Route 53 + Cloudflare) so an outage at one doesn't take you down.
On October 21, 2016, Twitter, Spotify, and GitHub were unreachable for several hours for many US users, even though their origin servers and CDNs were healthy. What was the failure mode?
Pick one answer.
You cannot change physics: recursive resolvers that have already cached 203.0.113.10 will keep serving it for up to TTL. The question is how to minimize the window.
Your primary data center in us-east-1 goes down hard. You have a warm standby in eu-west-1. Your DNS A record points to 203.0.113.10 (us-east-1) with a 1-hour TTL. How do you fail over with minimal user-visible downtime?
Engineering mental model
Mental model. Think of DNS — Domain Name System as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does DNS — Domain Name System mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing DNS — Domain Name System, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = dns(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: DNS — Domain Name System
Change the variables below and predict what breaks first in DNS — Domain Name System. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on DNS — Domain Name System, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using DNS — Domain Name System. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using DNS — Domain Name System?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses DNS — Domain Name System, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose DNS — Domain Name System, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for DNS - Domain Name System: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using DNS - Domain Name System. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +Hierarchical and distributed — no single server holds the entire database.
- +Aggressive caching keeps query latency low (usually <10ms after first lookup).
- +TTL-based caching gives operators explicit control over propagation speed.
- −DNS is a single point of failure for your domain. If your authoritative NS is down, you are unreachable.
- −Propagation is eventual, not instant. A misconfigured record can take hours to undo.
- −Originally unencrypted — ISPs and middlemen can snoop and hijack. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) fix this.
How this breaks in production
- Authoritative nameserver outage — your domain becomes unreachable globally.
- DNS cache poisoning — users redirected to malicious IPs.
- TTL too long — a misconfigured record takes hours to undo globally.
Don't fall into these traps
- •Treating DNS as 'always works'. DNS outages are real and take down even the biggest companies.
- •Forgetting to lower TTL before a planned migration, then waiting hours for propagation.
- •CNAME at the apex domain. This is invalid in RFC 1033 — use ALIAS/ANAME or a redirect.
- •Single authoritative nameserver provider. Use two providers for redundancy.
Real systems using this
How real systems implement this
- Cloudflare DNS — 1.1.1.1 public resolver with sub-10ms global anycast. Authoritative + recursive in one platform.
- AWS Route 53 — Managed DNS with weighted routing, health checks, and failover policies.
Practice saying it out loud
- Q1Explain what happens when you type example.com into your browser, focusing on DNS.
- Q2How would you design DNS to survive a single nameserver failure?
- Q3Your DNS change has not propagated for some users 12 hours later. What could be wrong?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
Load Balancers