DNS & Domain Resolution

The Invisible Directory Behind Every Website

Think about the last time you typed “google.com” into your browser. Seconds later, you’re on Google’s homepage. But here’s a question: how did your browser know where to find Google’s servers? You typed a name, not a number. Your computer needs an address—a numeric Internet Protocol (IP) address—to locate another machine on the network. Yet we humans don’t remember that Google’s IP is 142.251.32.46. We remember “google.com.”

This gap between human-friendly names and machine-required numbers is exactly what DNS solves. DNS stands for Domain Name System, and it’s essentially the phonebook of the internet. Without it, the web would be unusable for everyday people. Instead of visiting websites by name, you’d need to memorize dozens of IP addresses. DNS quietly bridges this gap every single day, billions of times.

We’ll explore how DNS works, why it matters for system design, and how to leverage it effectively when building scalable applications. Understanding DNS deeply helps you design resilient systems, optimize global performance, and gracefully handle failovers.

What DNS Really Is

DNS is a distributed, hierarchical system that translates domain names into IP addresses (and other information). It’s not a single server somewhere; it’s a massive network of interconnected servers that work together to answer one question: “What is the IP address for example.com?”

The internet uses a hierarchical naming structure to organize domains. At the very top sits the root (represented by a dot: .). Below that are top-level domains (TLDs) like .com, .org, .net, and country codes like .uk or .jp. Below TLDs are second-level domains, which is where most organizations register their names: “google” in “google.com.” Finally, subdomains let you create logical divisions: “mail.google.com” or “api.example.com.”

DNS isn’t just about A records (the standard IPv4 address records). There are several record types, each serving a specific purpose. An A record maps a domain to an IPv4 address. An AAAA record does the same for IPv6 addresses (the newer 128-bit standard). A CNAME record creates an alias—it points a domain to another domain. An MX record specifies which mail servers handle email for that domain. NS records identify the authoritative nameservers for a domain. TXT records store arbitrary text, often used for security verification.

Every DNS record has a TTL (Time To Live), measured in seconds. This number tells DNS caches how long they can serve a record before checking with the authoritative server again. A TTL of 300 means “trust this answer for 5 minutes.” A TTL of 86400 means “trust this for a full day.” This is a crucial trade-off we’ll revisit: short TTLs enable fast updates but increase query load; long TTLs reduce load but slow down changes.

DNS resolution comes in two flavors: recursive and iterative. In recursive resolution, your browser asks a recursive resolver to find the answer, and the resolver does all the work—asking the root, then the TLD server, then the authoritative server, then handing you the final answer. In iterative resolution, each server tells you “I don’t know, but ask this server next,” and you keep asking until you find the answer. In practice, your browser uses a recursive resolver (provided by your ISP or a service like 8.8.8.8), which then uses iterative queries internally.

From Phonebook to Internet Directory

Imagine a massive physical phonebook with billions of entries. When you need someone’s number, you’d look it up once and write it down. If you needed it again, you wouldn’t flip through the book; you’d use your notes. If someone moved to a new address, the phonebook would eventually update, but your notes wouldn’t—until you check the book again.

That’s exactly how DNS works. Your computer is the person with notes (the DNS cache). The massive phonebook is the distributed DNS system. When you visit a website, your machine looks in its notes first (local cache). If it’s there and still fresh (within the TTL), you’re done. If not, you ask a library assistant (recursive resolver) to look it up in the main book and bring back the answer. The assistant might ask several supervisors (DNS servers) before finding the right desk (authoritative nameserver) with the actual record.

Just like a phonebook needs multiple copies in different cities to serve everyone, DNS is distributed globally. No single point of failure, no single bottleneck. Elegant and proven over decades.

The Complete Journey of a DNS Query

Let’s trace what happens when you type “example.com” into your browser:

Browser → OS Cache → Recursive Resolver → Root Server → TLD Server → Authoritative Server → Answer

Step 1: Browser Cache. Your browser checks its own DNS cache first. Popular sites you’ve visited recently are stored there. If found and still fresh (within TTL), the browser uses it immediately. This is the fastest path.

Step 2: Operating System Cache. If the browser doesn’t have it, the OS cache is checked. Your operating system (Windows, macOS, Linux) maintains its own DNS cache. Again, if it’s fresh, you get an instant answer.

Step 3: Recursive Resolver Query. If neither cache helps, your operating system sends a query to a recursive resolver—typically provided by your ISP or a public service like Google’s 8.8.8.8, Cloudflare’s 1.1.1.1, or Quad9’s 9.9.9.9. This resolver has its own cache and will do the detective work.

Step 4: Root Server. The resolver asks a root server: “Where can I find .com domains?” There are only 13 root servers (labeled A through M), but they’re replicated globally. The root server responds with the address of a TLD server.

Step 5: TLD Server. The resolver now queries the TLD server for .com: “Where can I find example.com?” The TLD server responds with the address of the authoritative nameserver for example.com.

Step 6: Authoritative Server. The resolver queries the authoritative nameserver: “What’s the IP for example.com?” This server has the actual answer and returns it.

Step 7: The Answer Returns. The recursive resolver caches the answer and sends it back to your OS, which caches it and sends it to your browser, which also caches it. Your browser now has the IP address and can open a connection.

This entire process usually takes 10–100 milliseconds, thanks to distributed caches at every level. Without caching, every single query would require asking all the way up the chain, which would be catastrophically slow.

Here’s a visual representation of the DNS resolution chain:

graph LR
    A["Your Browser<br/>(with cache)"]
    B["Recursive Resolver<br/>(with cache)"]
    C["Root Server"]
    D["TLD Server<br/>(.com, .org, etc.)"]
    E["Authoritative Server<br/>(example.com owner)"]

    A -->|"1. Recursive query<br/>(example.com?)"| B
    B -->|"2. Iterative query"| C
    C -->|"3. Here's the TLD server"| B
    B -->|"4. Iterative query"| D
    D -->|"5. Here's the authoritative server"| B
    B -->|"6. Iterative query"| E
    E -->|"7. IP: 93.184.216.34"| B
    B -->|"8. Answer cached & returned"| A

Now let’s look at what a real DNS query looks like using the dig command:

$ dig example.com

; <<>> DiG 9.16.1-Ubuntu <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		3599	IN	A	93.184.216.34

;; AUTHORITY SECTION:
example.com.		172800	IN	NS	a.iana-servers.net.
example.com.		172800	IN	NS	b.iana-servers.net.

;; Query time: 45 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Feb 10 2024 14:22:00 UTC
;; MSG size  rcvd: 96 bytes

This tells us that example.com resolves to 93.184.216.34, the response was cached (notice the TTL of 3599 seconds—almost an hour), and the query took 45 milliseconds.

DNS Propagation is the time it takes for a DNS change to spread across the internet. When you update a DNS record (like changing your website’s IP), it doesn’t instantly appear everywhere. The old record lives in caches across the globe. Depending on the previous record’s TTL, propagation can take minutes (if TTL was short) or hours (if TTL was long). This is why you’re advised to lower the TTL before a major change—it ensures caches expire faster and pick up the new record quickly.

DNS Load Balancing allows you to distribute traffic across multiple servers using DNS. The simplest approach is round-robin: a single domain maps to multiple IP addresses, and DNS returns them in rotating order. Browser clients typically connect to the first one in the list, distributing load naturally. More sophisticated approaches include geo-based routing, where DNS returns different IPs based on the client’s geographic location, enabling global load balancing. For example, users in Europe might resolve to a European data center, while users in Asia get an Asian server.

How DNS Powers System Design

DNS isn’t just infrastructure; it’s a powerful tool for system design. Understanding it helps you build resilient, scalable, global systems.

Content Delivery Networks (CDNs) like Cloudflare, Akamai, and AWS CloudFront rely heavily on DNS. When you request a resource, DNS resolves to a geographically close edge server rather than your origin. The CDN’s DNS servers detect your location and return the nearest edge server’s IP. This reduces latency dramatically.

Failover and High Availability can be implemented via DNS. If a primary server fails, you update DNS to point to a backup. However, because of TTL caching, clients won’t immediately switch—they’ll keep using the old IP until their cache expires. This is why short TTLs are valuable for critical services. Some systems use health checks at the DNS level: nameservers actively monitor server health and only return IPs of healthy servers.

Blue-Green Deployments (running two identical production environments and switching between them) become easy with DNS. Deploy to the “green” environment, test thoroughly, then change DNS to point to green. If issues arise, flip DNS back to blue in seconds. No waiting for caches to expire, no gradual rollouts.

Global Load Balancing across data centers uses DNS geo-routing. A company with data centers in US, EU, and Asia configures their DNS to return geographically appropriate IPs, ensuring users connect to the nearest facility and reducing latency globally.

Real-world example: You’re building a payment processing system that must never go down. You deploy identical systems in three regions. Each region has its own authoritative nameserver. You configure a recursive resolver with health checks: if the US servers are down, DNS stops returning US IPs and redirects traffic to EU or Asia. Users experience slightly higher latency but service never stops.

The Trade-offs of DNS Design

TTL Strategy is a fundamental decision. Short TTLs (60–300 seconds) let you change routing quickly and enable elegant failover. The cost: many more DNS queries, extra load on recursive resolvers and authoritative servers, and slightly higher latency because caching is less effective. Long TTLs (86400 seconds or more) reduce query load and network traffic significantly. The cost: slow deployment velocity, delayed failover, longer propagation times.

The sweet spot depends on your service. For critical services with frequent changes, TTLs of 300–600 seconds are common. For static content that never changes, 86400 or longer is fine. Many systems use different TTLs for different records: short TTLs for DNS records that change, long TTLs for stable records.

DNS as a Single Point of Failure. If all your DNS queries go to one resolver, and that resolver is slow or down, your entire service becomes unreachable—even if your servers are healthy. This is why public recursive resolvers (8.8.8.8, 1.1.1.1) are valuable; they’re distributed globally and highly redundant. Also, redundancy in authoritative nameservers is mandatory: most domains have at least two authoritative nameservers, and many have more.

DNS Security is increasingly important. DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses, proving they haven’t been tampered with. However, DNSSEC adds complexity and slight performance overhead. DNS over HTTPS (DoH) encrypts DNS queries so ISPs and network observers can’t see which sites you visit. It’s great for privacy but adds a tiny latency penalty. Most systems don’t implement these unless privacy or integrity are critical concerns.

Another security consideration: DNS can be weaponized. In a DNS amplification attack, an attacker sends spoofed queries to many recursive resolvers, asking them to return large responses to a victim’s IP address, flooding the victim with traffic. Mitigation involves rate limiting and proper DNS configuration.

Key Takeaways

DNS is the internet’s phonebook, translating human-readable domain names into IP addresses that computers use.
Hierarchy and caching make DNS fast and scalable: browsers, operating systems, and recursive resolvers all cache results, so most queries never hit authoritative servers.
TTL is a critical trade-off: short TTLs enable fast updates and graceful failover but increase query load; long TTLs reduce load but slow deployments.
DNS enables powerful system design patterns: CDNs, failover, load balancing, and blue-green deployments all depend on DNS routing.
DNS is distributed by design, with root servers, TLD servers, and authoritative servers spread globally, preventing any single point of failure at the DNS layer.
DNS isn’t just logistics; it’s a business lever for performance, availability, and user experience.

Practice Scenarios

Scenario 1: Speeding Up a Migration. You’re migrating your website from server A (IP 1.2.3.4) to server B (IP 5.6.7.8). Your current DNS record has a TTL of 86400 seconds. Users won’t see the new server for up to 24 hours. What’s your strategy to minimize downtime and ensure users see the new server quickly?

Scenario 2: Global Resilience. Your e-commerce platform serves customers worldwide. You have data centers in New York, London, and Singapore. You want users in each region to automatically connect to the nearest data center for lowest latency, but if a data center fails, traffic should route to the next closest one. How would you use DNS to achieve this?

Scenario 3: TTL Tuning for Chaos. You’re running a chaos engineering exercise where you deliberately fail servers to test your system’s resilience. Your DNS TTL is 3600 seconds. Servers take 5 seconds to fail and 2 minutes to fully recover. Why is your current TTL problematic, and what TTL would you use?

Connecting to the Next Layer

We’ve explored how DNS translates names into addresses, the foundation of reaching any server. But once you have the IP address, what happens next? Your browser opens a connection and starts speaking the HTTP protocol—the language of the web. In the next chapter, we’ll dive deep into HTTP and HTTPS, understanding how data actually flows, why HTTPS is non-negotiable, and how protocol versions (HTTP/2, HTTP/3) improve performance and reliability. You’ll see how DNS, TCP, and HTTP work together as a seamless stack.