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. The system involves billions of records and thirteen root server clusters. That system is the Domain Name System. Understanding how DNS works is valuable for developers, IT professionals, 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 by acting as a translation layer between the names we remember and the addresses machines need. This guide walks through the entire DNS resolution process step by step in plain English. You will 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. Often called the phonebook of the internet, DNS replaced the original HOSTS.TXT file approach in 1983. The protocol is defined in RFC 1035 (1987) and handles trillions of queries every day across billions of records.

The Domain Name System 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. If they don’t have it, they direct you to a more specialized librarian who does. The process continues until someone finally hands you the book you need.

DNS was created in 1983 by Paul Mockapetris. He 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. The underlying servers and infrastructure remain online, but users cannot reach them. DNS operates at Layer 7 (Application) of the OSI model. DNS failures are one of the most common issues covered in network troubleshooting.

The DNS Resolution Chain

When you type a URL, the DNS resolution process follows a specific chain of up to seven lookups. The chain starts with your browser cache and ends at the authoritative nameserver for the domain. Each step either produces an answer from cache or points to the next place to look.

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. The browser 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. This is 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. It is also called a recursive DNS server or simply a “resolver.” This is usually a DNS server operated by your Internet Service Provider (ISP). 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. It queries multiple other DNS servers as needed. Think of it as a research assistant. You give it a question. It does all the legwork to find the answer, no matter how many sources it must consult. The resolver also maintains its own cache. 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 Verisign, NASA, ICANN, the U.S. Department of Defense, plus universities and research institutions.

Despite the 13 addresses, hundreds of physical servers are 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. The root server looks at the .com part of the query and responds with a referral. The referral reads: “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 has its own set of nameservers. This includes .com, .org, .net, .io, .dev, and country codes like .uk and .de.

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.” You can see which authoritative nameservers any domain uses by running a WHOIS or RDAP lookup. The lookup returns the registered nameservers as part of the domain record.

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. 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 typically takes between 20 and 120 milliseconds for an uncached lookup. That covers the time from your keystroke to the first byte of the webpage arriving. Cached lookups return in under a millisecond. Every level in the chain caches the result. Subsequent requests for the same domain skip most or all of these steps.

Recursive vs Iterative DNS Queries

Two query types exist in DNS. A recursive query demands a complete answer from the server. An iterative query accepts the best answer the server has now, which may be a referral. Your computer sends recursive queries to its resolver. The resolver then sends iterative queries to root, TLD, and authoritative servers.

Two types of DNS queries exist. 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. 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. The DNS cache exists at multiple levels: browser, operating system, and recursive resolver. Each level stores answers for a period defined by the TTL (Time to Live) value. Common TTLs range from 300 seconds (5 minutes) to 86,400 seconds (24 hours), set by the domain administrator.

Caching is what makes DNS fast. Without it, every webpage load would trigger a full chain of queries. The resolver would query all the way to the root servers and back. The DNS cache exists at multiple levels: browser, operating system, and recursive resolver. 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 are not instant. Propagation depends on TTL values across all the caches that hold the old record. The actual wait is usually much shorter than the often-cited “24 to 48 hours.” See our guide on how long DNS propagation actually takes for the practical timing.

You can flush your local DNS cache 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. These show 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

Five types of DNS servers exist. Recursive resolvers do the work of chasing answers. Root nameservers direct queries to TLDs. TLD nameservers point to authoritative servers. Authoritative nameservers hold the actual records. Forwarding servers pass queries through to other resolvers without doing recursion themselves.

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

Public DNS Resolvers

Public DNS services often offer better performance, reliability, and privacy than the default ISP resolver. Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9), and OpenDNS are the four most popular options. Each supports encrypted DNS protocols including DNS over HTTPS and DNS over TLS.

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 simple. Three options exist. Change the DNS settings in your operating system’s network configuration. Update your router’s admin panel, which applies the change to every device on your network. Or configure DNS in individual applications.

DNS Security

DNS was designed in the 1980s without encryption or authentication. Several technologies address these gaps. DNSSEC adds cryptographic signatures to records. DoH and DoT encrypt queries in transit. The newer DNS over QUIC (RFC 9250) combines encryption with the speed advantages of QUIC transport.

DNS was designed in the 1980s without encryption or authentication. 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. 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. The disclosure 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. The verification confirms that the record hasn’t been tampered with and actually 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. Firefox enabled DoH by default for US users in 2020. Chrome supports automatic upgrade to DoH when the configured resolver supports it. Because DoH traffic looks identical to regular HTTPS traffic, it is difficult to block or inspect. This is 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. It 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.

DNS over QUIC (DoQ)

DNS over QUIC is the newest encrypted DNS protocol, defined in RFC 9250 (2022). It combines DNS with the QUIC transport protocol used by HTTP/3. The benefits include faster connection establishment, better handling of packet loss, and the same encryption guarantees as DoT. AdGuard DNS launched the first public DoQ resolver in 2020, and NextDNS followed. In March 2026, Quad9 became the first infrastructure-grade public resolver to enable DoQ. The same announcement added DNS over HTTP/3 (DoH3), which runs DoH on QUIC transport. Browsers that support HTTP/3 upgrade to DoH3 automatically. Adoption is still growing, but DoQ is positioned to become the long-term default for encrypted DNS as HTTP/3 adoption increases. TLS certificates underpin both DoH and DoT, while DoQ uses QUIC’s own certificate validation built on the same trust chain.

For maximum privacy, use a DNS resolver that supports encrypted DNS (DoH, DoT, or DoQ). Choose one that 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. It investigates which domains point to a given IP address. Or explore how reverse DNS works to understand the relationship between IPs and hostnames.

Related Tools & Resources

NetworkCheckr offers complementary tools for DNS workflows. The DNS Lookup tool queries A, AAAA, MX, and other forward records. The Reverse DNS Lookup performs PTR queries. The WHOIS Lookup reveals registered nameservers and ownership data for any domain.

• DNS Lookup — query A, AAAA, MX, TXT, and other DNS records for any domain.
• Reverse DNS Lookup — perform PTR queries for any IP address.
• WHOIS Lookup — reveal registered nameservers and domain ownership data.
• My IP Address — check your public IP and its associated hostname.
• DNS Records Explained — reference guide for A, AAAA, MX, CNAME, TXT, and other record types.
• How Long Does DNS Propagation Take? — practical guide to TTL and propagation timing.
• What Is Reverse DNS? — companion guide on PTR records and email deliverability.
• All NetworkCheckr Tools — the full set of free networking utilities.

Frequently Asked Questions

Six questions cover the practical edge cases. The difference between recursive and authoritative servers. How long resolution actually takes. What happens when DNS fails. Whether your ISP can see your queries. What DNS over HTTPS does. And how to change your DNS server on each operating system.