Domain Name System (DNS)

The Phone Book of the Internet

When you type google.com into your browser, your computer doesn't actually know where Google lives. It just knows a name. Somewhere, a translation needs to happen, translating the human-friendly name google.com to a machine-friendly IP address like 142.250.80.46.

That translation service is DNS, the Domain Name System. It's often called the "phone book of the internet," and while that analogy is a bit dated, it captures the essence: DNS maps names to numbers.

The remarkable thing about DNS is that it's a massively distributed, globally consistent system that handles trillions of lookups per day with sub-millisecond latency. It's one of the most impressive pieces of infrastructure on the internet, and most people never think about it until it breaks.

The DNS Resolution Process

The DNS resolution process translates a hostname into an IP address. Let's trace through it step by step.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

DNS cold lookup — the full resolution chain when nothing is cached. Your browser asks a recursive resolver (e.g. Google's 8.8.8.8), which works its way down the hierarchy: root nameservers know who handles .com, TLD nameservers know who handles example.com, and the authoritative nameserver holds the actual A record. The whole process takes 20-120ms. The resolver caches the result for the record's TTL.

1 / 10.5×1×2×3×Playground

DNS cold lookup resolution chain

Step 1: Check the Cache

Your computer first checks its local DNS cache. If you've visited example.com recently and the cached entry hasn't expired, it uses that IP directly without any network request needed.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Cached lookup — the fast path. On your second visit, the OS DNS cache (in-memory) returns the IP in under 1ms without any network calls. If the OS cache has expired, the recursive resolver's cache likely still has it — ~5ms instead of 100ms. TTL controls how long these caches hold entries: a 300-second TTL means stale data for up to 5 minutes after a change.

1 / 10.5×1×2×3×Playground

Cached DNS lookup fast path

Your OS also checks /etc/hosts (on Linux/Mac) or the Windows hosts file, where you can manually define name-to-IP mappings. This is how local development tricks like 127.0.0.1 myapp.local work.

Step 2: Ask the Recursive Resolver

If there's no cached answer, your computer asks a recursive resolver (also called a recursive nameserver). This is typically provided by your ISP, or you might use a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.

The recursive resolver is the workhorse. It does the heavy lifting on your behalf, querying other servers until it finds the answer.

Step 3: Ask the Root Nameservers

If the recursive resolver doesn't have the answer cached, it starts at the top: the root nameservers. There are 13 root nameserver clusters (labeled A through M), distributed globally. They don't know the IP of example.com, but they know who does: the TLD nameserver.

Step 4: Ask the TLD Nameserver

The root server points the resolver to the TLD (Top-Level Domain) nameserver for .com. The TLD nameserver knows which authoritative nameservers are responsible for example.com.

Step 5: Ask the Authoritative Nameserver

Finally, the resolver asks example.com's authoritative nameserver, which is the server that actually holds the DNS records for that domain. This is typically managed by your domain registrar (Namecheap, GoDaddy) or DNS provider (Cloudflare, Route 53).

The authoritative server returns the answer: "www.example.com is at 93.184.216.34."

Step 6: Cache and Return

The recursive resolver caches the result (for as long as the TTL specifies) and returns it to your computer. Your computer caches it too. Your browser finally connects.

This whole process typically takes 20-120 milliseconds on a cold lookup. After that, cached lookups are essentially instant.

DNS Record Types

DNS is more than just name-to-IP. There are different record types for different purposes:

A Record

Maps a hostname to an IPv4 address. The most common record type.

AAAA Record

Maps a hostname to an IPv6 address.

CNAME Record

A canonical name record is an alias from one name to another. Instead of an IP, it points to another hostname.

CNAMEs are useful for pointing subdomains to your main domain, or pointing your domain at a service provider (like shop.example.com → your-store.shopify.com). You can't use a CNAME at the root of a domain (@); instead, use an A record or your DNS provider's ALIAS/ANAME feature.

MX Record

Specifies the mail servers for a domain. When someone sends email to user@example.com, their mail server looks up the MX record to know where to deliver it.

The number (10) is the priority, where lower means higher priority.

TXT Record

Stores arbitrary text data. Mostly used for:

• Email authentication (SPF, DKIM, DMARC)
• Domain verification (Google, AWS, etc. ask you to add a TXT record to prove you own a domain)

NS Record

Specifies which nameservers are authoritative for a domain. These are set at your registrar when you delegate a domain to a DNS provider.

TTL and Caching

TTL (Time To Live) is the number of seconds DNS resolvers should cache a record before re-querying. It's set on each DNS record.

• Short TTL (60-300 seconds): resolvers re-fetch frequently. Useful when you're about to change an IP and want propagation to be fast.
• Long TTL (3600-86400 seconds): less DNS traffic, faster lookups (cache hits). Good for stable, rarely-changing records.

DNS propagation refers to the time it takes for a DNS change to spread across all resolvers and caches. With a TTL of 24 hours, some users could see the old IP for up to a day after you change it. Pro tip: lower your TTL to 60 seconds before making a change, then restore it after.

DNS as a Load Balancer

DNS can distribute traffic without any dedicated load balancer hardware.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Geo-DNS — returning different IPs based on where the request comes from. AWS Route 53 and Cloudflare use this to route US users to US servers and EU users to EU servers, reducing latency by hundreds of milliseconds. It's also how CDNs route users to their nearest edge node. The limitation: DNS caches the decision, so failover can take minutes to propagate if a server goes down.

1 / 10.5×1×2×3×Playground

Geo-DNS routing users based on location

Two common techniques:

Round-robin DNS: Return multiple A records for a domain. Each resolver rotates through them.

Geo-DNS / Latency-based routing: Services like AWS Route 53 or Cloudflare can return different IPs based on the requester's location. US users get a US server IP; EU users get an EU server IP. This reduces latency and is how global CDNs work at the DNS level.

DNS-based load balancing has limitations: clients cache the IP and keep using it, so you can't quickly drain one server. It's best for coarse-grained traffic distribution, not fine-grained health-aware routing.

DNS in System Design

A few places DNS comes up in design discussions:

• Service discovery in microservices: Kubernetes, Consul, and other platforms use internal DNS to let services find each other by name instead of hardcoded IPs.
• Failover and disaster recovery: DNS failover (via health-check-aware DNS like Route 53) can reroute traffic from a failed region in minutes.
• CDN routing: CDNs use DNS to route users to the nearest edge node.
• Security (DNS over HTTPS / DoH): Traditional DNS is unencrypted. DoH encrypts DNS queries inside HTTPS, preventing ISPs and attackers from seeing what sites you're looking up.

Summary

DNS is the distributed system that translates human-readable domain names into IP addresses. Resolution follows a chain: local cache → recursive resolver → root nameserver → TLD nameserver → authoritative nameserver. Different record types serve different purposes: A/AAAA for IP mapping, CNAME for aliases, MX for email, TXT for verification, NS for delegation. TTL controls how long records are cached and directly impacts propagation time when you make changes. DNS can also serve as a basic load balancer and geo-router. It's infrastructure-level knowledge that surfaces constantly in system design, from VPC networking to CDN configuration to microservice discovery.