How DNS Works — A Practical Guide for DevOps & Developers

Every time you type www.google.com into your browser and hit enter, something magical happens in milliseconds. Your computer doesn't actually know where Google lives on the internet. It needs to ask for directions. This is where the Domain Name System, or DNS, comes into play—the internet's phonebook, working tirelessly behind the scenes to translate human-readable domain names into machine-readable IP addresses.

Let's embark on a journey following a single DNS query from the moment you press enter to the moment your browser connects to the server. We'll explore every cache check, every server hop, and every decision point along the way.

The Beginning: You Press Enter

Imagine you've just typed www.example.com into your browser's address bar. The moment you press enter, your browser springs into action. But here's the thing: computers don't speak in domain names. They speak in numbers—specifically, IP addresses like 192.0.2.1. Your browser needs to translate that friendly name into an IP address before it can load the website.

Step 1: The Browser Cache Check

Before asking anyone else, your browser checks its own memory. Modern browsers maintain a DNS cache—a temporary storage of recently visited domain names and their corresponding IP addresses. This cache exists because efficiency matters. If you visited www.example.com five minutes ago, why ask the entire internet again?

The browser looks through its cache, searching for an entry matching www.example.com. Each cached entry has a TTL (Time To Live)—a countdown timer set by the domain owner that determines how long the browser should trust this information. If the browser finds a valid, non-expired entry, the journey ends here. The browser uses that cached IP address immediately, and your page starts loading. This happens in microseconds.

But let's assume this is your first visit, or the cache has expired. The browser finds nothing. The journey continues.

Step 2: The Operating System Cache

Your browser now makes a system call to your operating system, asking: "Do you know where www.example.com is?" Your OS maintains its own DNS cache, separate from the browser. This cache is shared across all applications on your computer—your email client, your messaging apps, your other browsers.

The operating system checks its DNS cache. On Windows, you can view this cache using the command ipconfig /displaydns. On Mac or Linux, the caching works slightly differently through the system's resolver, but the concept remains the same: recently resolved domain names are stored temporarily.

If your OS has recently resolved this domain name for any application, it will return the IP address immediately. But in our scenario, it's a fresh query. The OS cache is empty. Time to look elsewhere.

Step 3: The Hosts File Check

Before venturing out onto the network, your OS checks one more local location: the hosts file. This is a simple text file that exists on every computer, a relic from the early days of networking. On Unix-like systems, it lives at /etc/hosts; on Windows, it's at C:\Windows\System32\drivers\etc\hosts.

The hosts file allows manual DNS overrides. System administrators use it for testing, developers use it to redirect traffic, and it can even be used to block unwanted domains by pointing them to 127.0.0.1 (your own computer). A typical entry looks like this:

If www.example.com is listed in the hosts file, that entry takes precedence over everything else. It's the ultimate override. But typically, for public websites, there's no entry here. The OS finds nothing and moves forward with the real DNS resolution process.

Step 4: Asking the Recursive Resolver

Now we leave your computer and venture onto the network. Your OS sends a DNS query to what's called a recursive resolver (also called a recursive DNS server). This is typically a server operated by your Internet Service Provider (ISP), though you might have configured your computer to use public DNS servers like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.

The recursive resolver is like a librarian. When you ask a question, the librarian doesn't necessarily know the answer off the top of their head, but they know how to find it. They'll search through catalogs, check different sections, and ask other librarians if needed—all on your behalf.

Your computer sends a DNS query packet over the network. This packet contains:

• The domain name you're looking for (www.example.com)
• The type of record you need (usually an A record for IPv4 addresses)
• Your computer's IP address (for the reply)
• Various flags and identifiers to track the request

The recursive resolver receives this query. And here's where things get interesting.

Step 5: The Recursive Resolver's Cache

The recursive resolver maintains a massive cache of DNS records. Unlike your personal computer, this server handles DNS queries for thousands or even millions of users. Popular websites like google.com, facebook.com, or youtube.com are almost certainly cached here because someone asked for them recently.

The resolver checks its cache for www.example.com. If it finds a valid entry (one whose TTL hasn't expired), it immediately returns the IP address to your computer. Your OS receives it, caches it, passes it to your browser, and the browser connects to the website. Total time: usually 10-50 milliseconds.

But let's say www.example.com isn't cached, or the cached entry has expired. Now the recursive resolver has to do what its name suggests: recursively query the DNS hierarchy on your behalf. This is where DNS gets really interesting.

Step 6: Querying the Root DNS Servers

The DNS system is organized as a hierarchy, like a tree turned upside down. At the very top (or root) of this tree are the root DNS servers. There are 13 sets of these root servers, labeled A through M (like a.root-servers.net through m.root-servers.net). Don't let the number 13 fool you—each "server" is actually a cluster of hundreds of machines distributed globally through a technique called anycast routing.

The recursive resolver knows the IP addresses of these root servers. They're hardcoded into DNS server software and updated only when necessary. The resolver sends a query to one of the root servers: "Where can I find information about www.example.com?"

The root server doesn't know where www.example.com is. That's not its job. But it does know who handles the .com domain. The root server looks at the rightmost part of the domain name (the top-level domain or TLD) and responds:

This response is called a referral. The root server has pointed the recursive resolver to the next step in the hierarchy. The resolver caches this information about the .com TLD servers—it won't need to ask the root servers again for any .com domain for a while.

Step 7: Querying the TLD DNS Servers

Armed with the addresses of the .com TLD servers, the recursive resolver now sends its query to one of them: "Where can I find information about www.example.com?"

The TLD server manages all domains ending in .com. It maintains a registry of which authoritative nameservers are responsible for which .com domains. When you register a domain like example.com, you specify your authoritative nameservers, and this information is stored in the TLD servers.

The TLD server responds with another referral:

These are the authoritative nameservers for example.com—the servers that have the actual, definitive information about this domain. The recursive resolver caches this information as well.

Step 8: Querying the Authoritative Nameservers

Finally, the recursive resolver contacts one of the authoritative nameservers for example.com. This is the end of the line—the authoritative nameserver has the definitive answer. The resolver asks: "What is the IP address for www.example.com?"

The authoritative nameserver looks up www.example.com in its zone file—a database of DNS records for the domain. It finds an A record (Address record) that looks like this:

Let's break down what this means:

• www.example.com. — The domain name (the trailing dot signifies the root of DNS)
• 3600 — The TTL in seconds (1 hour). This tells caching servers how long to remember this information
• IN — Internet class (almost always IN, a holdover from when other network classes existed)
• A — Record type (A for IPv4 address; AAAA would be for IPv6)
• 93.184.216.34 — The IP address where www.example.com is hosted

The authoritative nameserver sends this complete answer back to the recursive resolver. This is an authoritative answer—the definitive, trustworthy response directly from the source.

Step 9: The Return Journey

The recursive resolver now has the answer: www.example.com is at IP address 93.184.216.34. Before sending this back to your computer, the resolver does something crucial—it caches this information.

The resolver stores several pieces of information in its cache:

• The IP address of www.example.com for 3600 seconds (1 hour)
• The nameservers for example.com (already cached from the TLD query)
• The TLD servers for .com (already cached from the root query)

Now, when the next user asks for www.example.com, the recursive resolver can answer immediately from its cache—no need to query the root, TLD, or authoritative servers. This is how DNS scales to handle billions of queries per day.

The recursive resolver sends the IP address back to your computer:

Step 10: Your Computer Receives the Answer

Your operating system receives the DNS response from the recursive resolver. It immediately caches this information in its DNS cache, respecting the TTL of 3600 seconds. For the next hour, any application on your computer that needs to connect to www.example.com will get this IP address instantly from the OS cache.

Your OS then passes the IP address to your browser, which also caches it in its browser cache. The browser now knows that to load www.example.com, it needs to connect to 93.184.216.34.

Step 11: Making the Connection

With the IP address in hand, your browser can now establish a connection to the web server. It initiates a TCP connection to 93.184.216.34 on port 80 (for HTTP) or port 443 (for HTTPS). The three-way TCP handshake occurs (SYN, SYN-ACK, ACK), and if it's HTTPS, a TLS handshake follows to establish encryption.

Finally, your browser sends an HTTP GET request for the webpage. The server responds with HTML, CSS, JavaScript, images, and other resources. Your browser renders the page, and you see the website appear on your screen.

The entire DNS resolution process—all those steps from browser cache to root servers to authoritative nameservers—typically takes between 20 and 120 milliseconds on a fresh query. Cached queries resolve in under 10 milliseconds. You never notice it happening.

The Complete Flow Visualized

Each arrow represents a potential cache check or network query

DNS Record Types: Beyond the A Record

While we've focused on A records (IPv4 addresses), DNS supports many types of records, each serving a specific purpose:

The Importance of TTL (Time to Live)

Throughout our journey, we've mentioned TTL multiple times. This deserves deeper exploration because it's central to how DNS scales and performs globally.

Every DNS record has a TTL value set by the domain owner. This number, measured in seconds, tells caching servers how long they can trust the information before checking back with the authoritative source. It's a delicate balance:

Common practice: Use long TTLs (24 hours) for stable infrastructure, but lower it to 5-10 minutes well before making changes. After the change is complete and verified, gradually increase the TTL back to normal.

How Fast Is DNS, Really?

Let's talk numbers. In the absolute worst case—where nothing is cached and the recursive resolver must query root → TLD → authoritative nameservers—a DNS lookup might take 100-200 milliseconds. This happens rarely because caching is so effective.

Here's what typical resolution times look like:

• Browser cache hit: <1 millisecond
• OS cache hit: 1-5 milliseconds
• Recursive resolver cache hit: 10-30 milliseconds
• Full recursive query (cold cache): 20-120 milliseconds
• DNS over HTTPS: Adds 10-50ms due to encryption overhead

For popular websites, the resolver cache hit rate approaches 95%, meaning most queries are answered in 10-30 milliseconds. Combined with browser and OS caching, subsequent visits to the same site often resolve in under a millisecond.

This is why DNS scales. Despite handling trillions of queries daily, the hierarchical structure and aggressive caching mean that root servers handle only a tiny fraction of all DNS queries (less than 1%), while recursive resolvers do most of the heavy lifting with their caches.

Why DNS Is So Fast: Anycast Magic

You might wonder how DNS responds so quickly despite handling trillions of queries daily. The secret is anycast routing. Multiple servers around the world share the same IP address. When you query 8.8.8.8 (Google DNS), you're automatically routed to the nearest server—Tokyo users connect to Tokyo, London users to London.

This is why DNS queries rarely take more than 20-30 milliseconds. You're not crossing oceans; you're connecting to a server nearby.

Real-World Example: What Happens When You Visit Google

Let's walk through a real example. You type www.google.com and press enter:

Total DNS resolution time: 11 milliseconds. You never noticed it happened.

DNS in Content Delivery Networks (CDNs)

Modern websites often use CDNs like Cloudflare, Akamai, or Amazon CloudFront to serve content from servers close to users. DNS plays a crucial role in making this work.

When you query a CDN-enabled domain, the authoritative nameserver doesn't return a simple A record with one IP address. Instead, it intelligently returns different IP addresses based on where you are. A user in Australia gets directed to an Australian server; a user in Germany gets directed to a German server.

This happens through GeoDNS—the authoritative nameserver examines where the DNS query is coming from and returns the optimal IP address for that location. The result: faster load times and better user experience globally.

Some CDNs take this further with DNS-based load balancing, returning different IPs based on server health, current load, or even time of day.