The Phone Book of the Internet
In 2016, a DNS provider called Dyn went down for a few hours. Suddenly, Twitter, GitHub, Netflix, Reddit, and dozens of major websites became unreachable, not because their servers were down, but because DNS resolution stopped working and nobody could look up their addresses anymore. DNS (Domain Name System) is the invisible foundation everything else depends on. When it fails, the internet effectively stops working.
Computers communicate using IP addresses like 142.250.80.46. Humans remember names like google.com instead. DNS is the translation layer between the two, and it's the most heavily used distributed database in the world, handling trillions of lookups every day.
How a DNS Lookup Actually Works
If you want to see this chain for yourself, run dig scaledojo.com (or nslookup on Windows) from a terminal. The output shows the TTL of the returned record in seconds, and you can literally watch that number count down if you run the same query again a few seconds later. It's a good way to build intuition for how caching layers behave instead of just reading about it.
When you type scaledojo.com into your browser, here's what happens behind the scenes:
You type: scaledojo.com
1. Browser cache -----> Have it? Yes -> Done (0ms)
No -> keep going
2. OS cache ----------> Have it? Yes -> Done (0ms)
No -> keep going
3. Router cache ------> Have it? Yes -> Done (1ms)
No -> keep going
4. ISP Recursive -----> Have it? Yes -> Done (5ms)
Resolver No -> ask the chain:
5. Root Server -------> "Try the .com TLD server" (20ms)
|
6. .com TLD Server --> "scaledojo.com is managed (40ms)
| by ns1.registrar.com"
|
7. Authoritative -----> "scaledojo.com = 1.2.3.4" (60ms)
Nameserver
Answer propagates back through the chain.
Total: 20-120ms for uncached, <5ms for cached.Most lookups never reach the root servers because caching at every level catches them first. Your ISP alone caches millions of DNS records, and the concepts here overlap a lot with general caching strategies you'd use anywhere else in a system.
TTL: How Long to Remember
TTL stands for Time To Live. When a DNS server gives you an answer, it includes a TTL value (in seconds) that says how long you're allowed to cache that answer. Think of it like a "use by" date on food: once the TTL expires, the cached answer gets thrown away and a fresh lookup happens.
TTL of 60 (1 minute) - used during migrations or failovers so changes propagate quickly
TTL of 300 (5 minutes) - common for dynamic services. If the IP changes, everyone gets the update within 5 minutes
TTL of 3600 (1 hour) - common for stable services, a good balance between freshness and performance
TTL of 86400 (24 hours) - for very stable infrastructure. Maximum caching, minimum DNS traffic
DNS in System Design
DNS is not just a lookup mechanism. Clever engineers use it as a load balancing and traffic routing tool:
Round-robin DNS - return multiple IP addresses and rotate which one comes first. Simple load distribution.
Geo-DNS - return different IPs based on where the user is located. A user in Tokyo gets the Tokyo server IP, a user in Paris gets the EU server IP.
Weighted DNS - send 90% of traffic to the primary and 10% to a canary deployment. Ideal for gradual rollouts.
Health-checked DNS - automatically remove unhealthy servers from DNS responses within seconds.
DNS failover - if the primary datacenter goes down, DNS automatically starts returning the backup datacenter's IP.
Geo-DNS in Action
User in Tokyo queries: api.example.com
-> Geo-DNS sees source IP from Japan
-> Returns: 103.22.xxx.xxx (Tokyo data center)
-> Latency: ~5ms
User in London queries: api.example.com
-> Geo-DNS sees source IP from UK
-> Returns: 52.86.xxx.xxx (EU-West data center)
-> Latency: ~10ms
Without Geo-DNS (single US data center):
Tokyo user latency: ~180ms
London user latency: ~90msThe TTL Trade-off in Practice
Watch out for CNAME chains when you're setting TTLs for load balancers. Many managed load balancers (classic AWS ELBs, for example) only give you a hostname, not a static IP, so you end up pointing a CNAME at that hostname. Each hop in the chain can carry its own TTL, and the effective cache time for the end user is really the shortest TTL in the chain, not the one you set on your own record. During a migration this catches people off guard more often than you'd expect.
Choosing the right TTL is a real engineering decision:
Low TTL (60s) means fast failover but more DNS queries hitting your authoritative servers, and slightly more latency for users due to more cache misses
High TTL (24h) means fewer DNS queries but slow failover. If a server dies, some users will keep trying the dead IP for hours.
During a planned migration, lower the TTL to 60s a day beforehand, do the migration, then raise it back afterward. This is a standard operations playbook.
DNS Failure Modes to Watch For
In system design interviews, these DNS edge cases show depth:
DNS amplification attacks: attackers send tiny DNS queries with a spoofed source IP, generating huge responses that flood the victim. This is why rate limiting on DNS resolvers matters.
TTL ignored by clients: some operating systems and browsers cache DNS beyond the TTL. During a migration, even a 60s TTL doesn't guarantee instant propagation.
Split-horizon DNS: returning different answers for internal vs. external queries. Your office network resolves api.example.com to an internal IP, while external users get the public IP.
DNS propagation delay: after changing a DNS record, it can take the full old TTL for all caches worldwide to expire. This is not instant.
Numbers That Matter
There are 13 logical root servers (actually ~1,500 instances via anycast) serving the entire internet
A DNS response is typically ~100-500 bytes, making it one of the lightest network operations around
Cloudflare's 1.1.1.1 resolver averages ~11ms response time globally
AWS Route 53 costs $0.50 per million queries, DNS is remarkably cheap at scale
A single DNS resolver can handle 50,000+ queries per second
Interview Tip
When designing any system in an interview, start with DNS. Say: "The user types the URL, DNS resolves it to our load balancer IP using Geo-DNS so they hit the nearest data center." This shows you understand the complete request path. Then mention TTL trade-offs for failover speed vs. cache efficiency, this kind of detail (along with knowing how an API gateway fits into the picture) in the first 30 seconds sets you apart.
Key Takeaway
DNS is a hierarchical caching system that translates names to IPs. TTL controls cache duration. In system design, DNS is your first load balancer and your first point of failure. Respect it.