How DNS Works

DNS: The Internet's Phone Book

The Domain Name System is the distributed database that translates human-readable domain names like example.com into machine-readable IP addresses like 93.184.216.34. Without DNS, you would need to memorize a numeric IP address for every website you visit — the way early ARPANET users maintained a single HOSTS.TXT file that mapped hostnames to addresses before the internet grew too large for any single file to track.

DNS was designed in 1983 by Paul Mockapetris and built on two principles: delegation and caching. No single server stores all domain records. Instead, authority over different portions of the namespace is delegated downward from the root, and every layer caches answers to avoid repeating the same lookups constantly. These two properties together allow DNS to scale to billions of domain names while delivering answers in milliseconds.

The Four DNS Server Types

A full DNS resolution involves four distinct types of servers, each playing a different role. Understanding each one clarifies what actually happens during a lookup.

The stub resolver lives on your device — it is a small client library built into your operating system. It does not know how to resolve domain names itself; it simply forwards queries to a configured recursive resolver and waits for a complete answer. The stub resolver also maintains a small local cache so that repeated queries for the same domain do not even leave the device.

The recursive resolver (also called a recursive nameserver or full-service resolver) does the actual work of following the DNS hierarchy. It receives the query from your stub resolver, checks its own cache, and if the answer is missing, navigates the hierarchy from root to TLD to authoritative nameserver to assemble the answer. Your ISP provides a recursive resolver by default, but public alternatives like Cloudflare (1.1.1.1) and Google (8.8.8.8) are also widely used.

The TLD nameserver holds information about the authoritative nameservers for every domain registered under a given top-level domain. The TLD nameserver for .com is operated by Verisign; for .org by the Public Interest Registry. It does not store actual DNS records for individual domains — it only knows which authoritative nameservers to delegate to for each registered domain.

The authoritative nameserver is the final, definitive source of truth for a specific domain's DNS records. It is operated by whoever controls the domain — a hosting provider, a CDN, or the domain owner's own infrastructure. When queried, it returns the actual record: the IP address, mail server, verification string, or whatever was requested.

The Full Lookup Walkthrough

When you navigate to www.example.com in your browser, the following sequence unfolds — typically in under 100 milliseconds on a healthy network:

Step 1: Your browser checks its own DNS cache. If it has a fresh entry, the lookup is complete immediately. Chrome caches DNS records for up to 60 seconds regardless of TTL.

Step 2: If not in the browser cache, the stub resolver in your OS checks the system DNS cache and the /etc/hosts file (or Windows equivalent). Again, a hit here ends the lookup immediately.

Step 3: The stub resolver sends a recursive query to your configured recursive resolver — your ISP's DNS or a public resolver. If the recursive resolver has a cached answer, it returns it directly.

Step 4: If the recursive resolver has no cache entry, it queries a root nameserver. It already knows the root server IP addresses from a built-in hints file. The root server does not know the answer but returns a referral: "For .com queries, ask these TLD nameservers."

Step 5: The recursive resolver queries the .com TLD nameserver. The TLD server returns a referral: "For example.com, ask these authoritative nameservers."

Step 6: The recursive resolver queries the authoritative nameserver for example.com. The authoritative server returns the A record — the IP address for www.example.com.

Step 7: The recursive resolver caches the answer according to its TTL and returns it to your stub resolver, which passes it to your browser. Your browser can now open a TCP connection to that IP address.

The Root Zone and the 13 Root Server Clusters

The DNS hierarchy begins at the root zone, represented by a single dot at the end of every fully qualified domain name (usually omitted in everyday use). The root zone is managed by ICANN and served by 13 named root server clusters, labeled A through M. The number 13 dates back to a limitation of the original DNS protocol: UDP packets were capped at 512 bytes, which could accommodate exactly 13 server records in a response.

Those 13 names do not represent 13 physical machines. Each is an anycast cluster — the same IP address announced from hundreds of physical servers distributed worldwide. When your recursive resolver queries a.root-servers.net, BGP routing automatically directs the query to the nearest physical instance of that cluster. ICANN tracks over 1,600 root server instances globally, ensuring that no single failure can disrupt the root zone.

TTL and Caching at Each Layer

Every DNS record carries a TTL (Time To Live) value measured in seconds. Once a resolver has cached a record, it serves that cached copy to all subsequent queries until the TTL expires. Only then does it contact the authoritative nameserver again to fetch a fresh value.

Caching happens at multiple independent layers: the browser, the OS resolver, and the recursive resolver each maintain their own cache. A record may have a TTL of 300 seconds (5 minutes) on the authoritative nameserver, but if the recursive resolver cached it 4 minutes ago, it will return the cached copy for the remaining 60 seconds and only re-query when that expires.

Short TTLs (60–300 seconds) allow DNS changes to propagate quickly around the world but increase the number of DNS queries hitting authoritative servers. Long TTLs (3600–86400 seconds) reduce DNS query volume and improve lookup speed for end users but slow down propagation when records need to change. Most production domains balance these concerns with TTLs of 300 to 3600 seconds.

DNS Uses UDP Port 53 by Default

DNS queries are sent over UDP on port 53. UDP was chosen over TCP because it is connectionless — a query and response require just two packets rather than the TCP handshake sequence, which keeps lookup latency minimal. Most DNS responses are small enough to fit in a single UDP packet.

When a DNS response exceeds 512 bytes (common for DNSSEC-signed records or responses with many A records), the server sets a truncation flag and the client retries the query over TCP, which supports arbitrarily large responses. Modern resolvers also use the EDNS(0) extension to negotiate larger UDP payload sizes up to 4,096 bytes, reducing the need for TCP fallback.

Cache Hit vs Cache Miss

The practical impact of caching on DNS speed is dramatic. A cache hit at the OS level returns an answer in under 1 millisecond. A cache hit at the recursive resolver level adds a round-trip to the resolver — typically 1–30 ms depending on distance. A full cache miss that traverses the complete chain adds 50–200 ms depending on network conditions and the geographic distribution of the servers involved.

For popular domains like major social networks and search engines, recursive resolvers always have cached answers because thousands of other users queried the same domain seconds ago. For obscure domains, a cold lookup on a distant resolver can noticeably delay the initial page load.

DNS Server Types Compared

Frequently Asked Questions

How long does a DNS lookup take?

A cached DNS lookup takes under 1 millisecond because the answer is stored locally on your device or in your recursive resolver. An uncached lookup that must traverse the full chain — recursive resolver, root nameserver, TLD nameserver, authoritative nameserver — typically takes between 20 and 120 milliseconds depending on network conditions and geographic distance to each server. Public DNS providers like Cloudflare (1.1.1.1) average around 11 ms globally for uncached queries.

What is a DNS cache?

A DNS cache is a temporary local store of previously resolved domain-name-to-IP-address mappings. Your operating system, browser, and recursive resolver all maintain their own caches. When a cached entry is available and its TTL has not expired, the lookup is answered immediately without contacting any external DNS servers. Caching dramatically reduces DNS lookup latency for frequently visited sites and reduces load on the global DNS infrastructure.

Why are there only 13 root DNS servers?

There are 13 root server IP addresses — labeled A through M — because the original DNS protocol used UDP packets limited to 512 bytes, which could only fit 13 root server records. However, each of those 13 IP addresses is actually an anycast cluster of hundreds of physical servers distributed worldwide. ICANN reports over 1,600 root server instances globally. When you query a root server, you automatically reach the nearest physical instance of that cluster.

What happens when a DNS server is down?

If your recursive resolver is unreachable, your browser cannot resolve any new domain names and you will see DNS-related errors. If an authoritative nameserver is down, the recursive resolver typically retries other NS records for the same domain — most domains publish two or more authoritative nameservers for redundancy. Cached results continue to work until their TTL expires, so recently visited sites may still resolve even when DNS infrastructure is degraded.

Can DNS affect internet speed?

DNS lookup time adds directly to the latency of the first connection to any domain your device has not visited recently. For a cached lookup this is under 1 ms and negligible. For an uncached lookup on a slow resolver it can add 80–200 ms before the TCP connection even begins. Switching to a faster resolver like Cloudflare (1.1.1.1) reduces this overhead on uncached lookups. DNS does not affect download speed or bandwidth once the connection is established.

What is a negative DNS cache entry?

A negative cache entry records that a domain does not exist — an NXDOMAIN response — so that future queries for the same non-existent domain can be answered immediately without repeating the full lookup chain. Negative caching is defined in RFC 2308. The duration of a negative cache entry is controlled by the SOA record's minimum TTL field for the domain's zone, typically set to a few minutes to a few hours.