How DNS Works: A Plain-English Walkthrough

You type www.example.com into your browser and press Enter. A fraction of a second later, a web page begins loading. It feels instant, but behind the scenes, your computer just completed a remarkable chain of lookups across a globally distributed system involving billions of records and thirteen root server clusters. That system is the Domain Name System, and understanding how DNS works is one of the most valuable things you can learn as a developer, IT professional, or anyone who manages websites.

The internet runs on IP addresses — numerical labels like 93.184.216.34 (IPv4) or 2606:2800:220:1:248:1893:25c8:1946 (IPv6). Computers have no trouble with these numbers, but humans do. Nobody wants to memorize a string of digits for every website they visit. DNS solves this problem by acting as a translation layer between the names we remember and the addresses machines need. In this guide, we will walk through the entire DNS resolution process step by step, in plain English, so you understand exactly what happens when you type a URL into your browser.

What Is DNS?

The Domain Name System (DNS) is a hierarchical, decentralized naming system that maps domain names to IP addresses. It is often described as the “phonebook of the internet,” but that analogy only scratches the surface. A more accurate comparison might be a chain of librarians: you ask the first librarian for a book, and if they don’t have it, they direct you to a more specialized librarian who does — until someone finally hands you the book you need.

DNS was created in 1983 by Paul Mockapetris, who authored RFC 882 and RFC 883 (later superseded by RFC 1035). Before DNS existed, the internet relied on a single file called HOSTS.TXT, maintained by the Stanford Research Institute. Every computer on the early internet downloaded this file to know where to find other computers. As the network grew from a few hundred hosts to thousands, this approach became completely unworkable. DNS replaced it with a distributed database that scales to billions of records and handles trillions of queries every day.

The domain name system is critical because virtually every internet interaction begins with a DNS query. Loading a webpage, sending an email, connecting to an API, streaming a video — all of these start with DNS. If DNS stops working, the internet effectively stops working for most users, even though the underlying servers and infrastructure remain online. DNS operates at Layer 7 (Application) of the OSI model, and DNS failures are one of the most common issues covered in network troubleshooting.

The DNS Resolution Chain

When you type a URL into your browser, the DNS resolution process follows a specific chain of lookups. Each step either produces an answer or points to the next place to look. Let’s walk through what happens when you type www.example.com and press Enter.

Step 1: Browser Cache

Your browser checks its own internal DNS cache first. Modern browsers like Chrome, Firefox, and Edge maintain a local cache of recently resolved domain names. If you visited www.example.com five minutes ago, your browser likely still has the IP address stored and can skip every subsequent step entirely.

In Chrome, you can inspect the browser’s DNS cache by navigating to chrome://net-internals/#dns. The cache typically holds entries for a few minutes, depending on the TTL value returned by the original DNS response. If the entry is found and hasn’t expired, the browser connects directly to the cached IP address. Resolution time: effectively zero.

Step 2: Operating System Resolver Cache

If the browser cache misses, the request moves to the OS resolver cache. Your operating system maintains its own DNS cache independent of any individual browser. On Windows, the DNS Client service manages this cache. On macOS and Linux, the system resolver handles it.

The OS cache also checks the local hosts file — a static file where you can manually map domain names to IP addresses. On Windows, this file lives at C:\Windows\System32\drivers\etc\hosts. On macOS and Linux, it’s at /etc/hosts. Developers often use the hosts file to redirect domains to 127.0.0.1 during local development. If the OS cache or hosts file has a match, the answer is returned immediately. If not, the query moves to the network.

Step 3: Recursive Resolver

This is where the real DNS resolution begins. Your computer sends the query to a recursive resolver — also called a recursive DNS server or simply a “resolver.” This is usually a DNS server operated by your Internet Service Provider (ISP), but it could also be a public DNS service like Google Public DNS (8.8.8.8) or Cloudflare (1.1.1.1).

The recursive resolver is called “recursive” because it will chase down the answer on your behalf, querying multiple other DNS servers as needed. Think of it as a research assistant: you give it a question, and it does all the legwork to find the answer, no matter how many sources it has to consult. The resolver also maintains its own cache, so if another user on the same ISP recently visited www.example.com, the resolver may already have the answer cached.

If the resolver has a cached answer, it returns it immediately. If not, it begins an iterative process, starting with the root nameservers.

Step 4: Root Nameservers

The recursive resolver contacts one of the root nameservers. There are 13 root server clusters, labeled A through M (for example, a.root-servers.net through m.root-servers.net). These 13 addresses are operated by organizations including Verisign, NASA, ICANN, the U.S. Department of Defense, and several universities and research institutions.

Despite there being only 13 addresses, there are actually hundreds of physical servers distributed around the world using anycast routing. When your resolver contacts a root server, it reaches the geographically closest instance.

Root nameservers don’t know the IP address of www.example.com. What they do know is which servers are responsible for top-level domains. So the root server looks at the .com part of the query and responds with a referral: “I don’t have the answer, but here are the nameservers for .com.”

Step 5: TLD Nameservers

The recursive resolver now contacts a TLD (Top-Level Domain) nameserver for .com. TLD nameservers are managed by registry operators — Verisign manages .com and .net, Public Interest Registry manages .org, and so on. Every TLD (.com, .org, .net, .io, .dev, country codes like .uk and .de) has its own set of TLD nameservers.

The TLD nameserver doesn’t know the IP address of www.example.com either. But it does know which authoritative nameservers are responsible for the example.com domain. It responds with another referral: “Here are the nameservers for example.com.”

Step 6: Authoritative Nameserver

The recursive resolver contacts the authoritative nameserver for example.com. This is the DNS server that actually has the definitive answer. It holds the DNS records for the domain — A records, AAAA records, MX records, CNAME records, and everything else.

The authoritative nameserver looks up the A record for www.example.com and responds with the IP address: 93.184.216.34. This is the first server in the entire chain that actually knows the final answer. If the domain uses a CNAME record, the authoritative server returns the canonical name, and the resolver may need to perform an additional lookup to resolve that name to an IP address.

Step 7: The Response Travels Back

The IP address now travels back through the chain in reverse. The authoritative nameserver sends it to the recursive resolver. The recursive resolver caches the answer (respecting the TTL value) and sends it to your operating system. Your OS caches it and passes it to the browser. The browser caches it, opens a TCP connection to 93.184.216.34, and begins loading the webpage.

The entire process — from your keystroke to the first byte of the webpage arriving — typically takes between 20 and 120 milliseconds for an uncached lookup. Cached lookups return in under a millisecond. Every level in the chain caches the result, so subsequent requests for the same domain skip most or all of these steps.

Recursive vs Iterative DNS Queries

There are two types of DNS queries, and understanding the difference between recursive vs iterative DNS queries is key to understanding how DNS works.

In practice, the process works like this: your computer makes one recursive query to your resolver, and your resolver makes several iterative queries to root, TLD, and authoritative servers to build the complete answer. Your computer never contacts root or TLD servers directly — the recursive resolver handles all of that.

DNS Caching and TTL

Caching is what makes DNS fast. Without caching, every single webpage load would require a full chain of queries from the resolver to the root servers and back. The DNS cache exists at multiple levels — browser, operating system, recursive resolver — and each level stores answers for a period defined by the TTL (Time to Live) value.

TTL is a value (in seconds) set by the domain administrator in their DNS records. Common TTL values include:

• 300 seconds (5 minutes) — common for records that change frequently or during migrations
• 3600 seconds (1 hour) — a typical default for most DNS records
• 86400 seconds (24 hours) — used for stable records that rarely change

When a TTL expires, the cached record is considered “stale” and the next request triggers a fresh lookup. This is why DNS changes aren’t instant — propagation depends on TTL values across all the caches that hold the old record.

If you need to flush your local DNS cache (useful when testing DNS changes), here are the commands for each operating system:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

You can verify a DNS lookup using command-line tools like nslookup or dig to see TTL values and confirm which nameserver is responding:

# Using dig to query a specific domain
dig www.example.com

# Using nslookup
nslookup www.example.com 8.8.8.8

Types of DNS Servers

Not all DNS servers are the same. Each type plays a specific role in the DNS resolution process.

Public DNS Resolvers

You are not limited to your ISP’s DNS resolver. Public DNS services often offer better performance, reliability, and privacy. Here is a comparison of the most popular options:

Switching to a public DNS resolver is straightforward. You can change the DNS settings in your operating system’s network configuration, in your router’s admin panel (which applies the change to every device on your network), or in individual applications.

DNS Security

DNS was designed in the 1980s without encryption or authentication, which means the original protocol has significant security weaknesses. Several technologies have been developed to address these vulnerabilities. DNS security intersects closely with firewall configuration, since firewalls control which DNS traffic is permitted on a network.

DNS Spoofing and Cache Poisoning

DNS spoofing (also called DNS cache poisoning) is an attack where a malicious actor injects forged DNS responses into a resolver’s cache. If successful, users who query that resolver are redirected to a malicious IP address — they think they’re visiting their bank’s website, but they’re actually on an attacker’s server. The Kaminsky attack, disclosed in 2008, demonstrated how this vulnerability could be exploited at scale and prompted widespread improvements to DNS implementations, including source port randomization.

DNSSEC

DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records. When a resolver receives a DNS response, it can verify the signature to confirm that the record hasn’t been tampered with and genuinely came from the authoritative nameserver. DNSSEC does not encrypt DNS traffic — it only provides authentication and integrity. While adoption has grown significantly, many domains still do not implement DNSSEC, and not all resolvers validate signatures.

DNS over HTTPS (DoH)

DNS over HTTPS encrypts DNS queries by sending them over HTTPS (port 443). This prevents ISPs, network administrators, and attackers from seeing which domains you are resolving. Major browsers including Chrome, Firefox, Edge, and Safari support DoH. Because DoH traffic looks identical to regular HTTPS traffic, it is difficult to block or inspect, which makes it valuable for privacy but controversial in enterprise environments that rely on DNS monitoring for security.

DNS over TLS (DoT)

DNS over TLS also encrypts DNS queries, but uses a dedicated port (853) rather than sharing port 443 with regular web traffic. This makes DoT easier to identify and manage on a network. Android 9 and later support DoT natively through the “Private DNS” setting. DoT provides the same privacy benefits as DoH but is more transparent to network administrators.

For maximum privacy, use a DNS resolver that supports encrypted DNS (DoH or DoT) and does not log your queries. Cloudflare (1.1.1.1) and Quad9 (9.9.9.9) are strong choices. You can also use tools like a reverse DNS lookup to investigate which domains point to a given IP address, or explore how reverse DNS works to understand the relationship between IP addresses and hostnames.

Frequently Asked Questions