How DNS Resolution Works: Step by Step, Server Types, Caching, and Failure Modes Explained

Every time you type pudgycat.io into a browser, a hidden relay race begins. Your computer does not actually know where that website lives. It only knows a name. To find the real address, it has to ask a small chain of servers, in order, and wait for the answer. That whole process is called DNS resolution, and it usually finishes in less than a tenth of a second. This guide explains how DNS resolution works step by step, what each server in the chain does, why caching matters, and what happens when something breaks. No prior networking knowledge needed.

Table of Contents

• What Is DNS and Why Do We Need It
• How DNS Resolution Works, Step by Step
• The Four Types of DNS Servers
• DNS Record Types You Should Know
• DNS Caching and TTL
• Recursive vs Iterative DNS Queries
• DNS Security: DNSSEC, DoH, and DoT
• When DNS Breaks: Common Failure Modes
• Frequently Asked Questions

What Is DNS and Why Do We Need It

The Domain Name System (DNS) is the internet’s address book. It maps human-readable names like pudgycat.io to numerical IP addresses like 185.199.108.153 for IPv4, or 2606:4700:4700::1111 for IPv6. Routers and switches do not understand names. They route packets using IP addresses only. DNS exists so humans never have to memorise the numbers.

Before DNS existed, every Unix machine on the early internet kept a single file called HOSTS.TXT, maintained by the Stanford Research Institute. Every time someone added a new computer to the network, an updated file had to be downloaded by hand. By 1983, with a few hundred hosts on ARPANET, the system was already breaking. Paul Mockapetris designed DNS that same year (RFCs 882 and 883), and the world switched to it in 1985. Forty years later, the basic design is still in place.

Names vs IP Addresses

An IP address is not a permanent label for a service. Big sites like Google, Cloudflare, and Netflix may map the same hostname to thousands of different IP addresses, returning a different one depending on where you are in the world. DNS is what makes that flexibility possible. Without it, every change of hosting provider would require notifying every visitor.

How DNS Resolution Works, Step by Step

Here is the full DNS resolution chain that runs when you type a URL and press Enter. We will use pudgycat.io as the example.

1. Browser cache check. Modern browsers keep an in-memory DNS cache. If pudgycat.io was visited in the last few minutes, the IP is reused immediately and the rest of the process is skipped.
2. Operating system cache check. If the browser cache misses, the request goes to the operating system. Windows, macOS, and most Linux distributions keep their own DNS cache through services like systemd-resolved, dnsmasq, or the Windows DNS Client.
3. Hosts file check. The OS reads a local file (/etc/hosts on Linux and macOS, C:\Windows\System32\drivers\etc\hosts on Windows) where the user can hardcode names. This is a manual override that wins over every other lookup.
4. Recursive resolver query. If no cache has the answer, the OS sends the question to a recursive DNS resolver. By default this is your internet provider, but it can be changed to public resolvers like Cloudflare 1.1.1.1, Google 8.8.8.8, or Quad9 9.9.9.9.
5. Root server query. The recursive resolver, if it does not have a cached answer, asks one of the 13 root DNS server clusters. The root server does not know where pudgycat.io lives, but it does know who handles the .io top-level domain.
6. TLD server query. The resolver asks the .io TLD server. The TLD server replies with the authoritative name servers for pudgycat.io, typically run by the domain registrar or DNS provider.
7. Authoritative server query. The resolver finally asks one of the authoritative servers for the exact IP address of pudgycat.io. This is where the real answer lives.
8. Answer returned and cached. The resolver sends the IP back to your OS, which sends it back to the browser. Every cache along the way stores it for next time, marked with a TTL.

From step 1 to step 8, the average DNS lookup on a fresh connection takes between 20 and 120 milliseconds. On a cached lookup, less than one millisecond. The reason modern websites feel instant is that almost every step above is short-circuited by caches.

The Four Types of DNS Servers

DNS resolution is a coordinated dance between four different kinds of servers. Each does one job.

1. Recursive Resolver

The resolver is the only server your computer talks to directly. It does all the work of querying the chain on your behalf and returns a single answer. The resolver is usually run by your ISP, but public alternatives exist. Cloudflare’s 1.1.1.1 promises sub-15-ms lookups and no logging. Google’s 8.8.8.8 is the most widely used public resolver. Quad9 (9.9.9.9) blocks known malicious domains at the resolver level.

2. Root Name Server

There are 13 logical root server identities, named A through M. Each one is operated by a different organisation and answers from hundreds of physical servers spread around the world using anycast routing. Despite the small number, the root layer handles billions of queries per day. Root servers do not store domain records. They only know which servers run each top-level domain.

3. TLD Name Server

The top-level domain server knows everything about its own TLD. The .com TLD server, for example, knows the authoritative servers for every .com domain ever registered. .io has its own TLD server, run by the operator of that registry. Country-code TLDs (.it, .uk, .jp) are handled by national registries.

4. Authoritative Name Server

This is the server that actually owns the record for a domain. When a domain owner changes the IP of their site, they update the record on the authoritative server. Big hosting providers run their own authoritative DNS (Cloudflare, AWS Route 53, Google Cloud DNS). Small sites typically use the DNS service of their registrar.

DNS Record Types You Should Know

A DNS lookup does not just return an IP. The authoritative server can return many different record types. Here are the ones you will run into most often.

• A record: maps a name to an IPv4 address. The most common record on the internet.
• AAAA record: maps a name to an IPv6 address. Pronounced “quad-A”.
• CNAME record: an alias. Points one name to another name (for example, www.example.com as an alias for example.com).
• MX record: mail exchange. Tells email servers where to deliver mail for the domain.
• TXT record: arbitrary text. Used for SPF, DKIM, domain ownership verification, and (in the wild west of internet plumbing) sometimes for service configuration.
• NS record: name server. Lists the authoritative DNS servers for a domain.
• PTR record: the reverse of an A record. Maps an IP back to a name. Used in reverse DNS lookups.
• SRV record: service location. Defines the hostname and port for a specific service (used by SIP, XMPP, Minecraft, and similar).
• CAA record: certificate authority authorisation. Tells the world which certificate authorities are allowed to issue HTTPS certificates for the domain.

You can inspect any of these from a terminal. On Linux and macOS, dig pudgycat.io returns the A record. dig -t MX pudgycat.io returns the mail records. On Windows, nslookup does the same job.

DNS Caching and TTL

Every DNS record comes with a TTL (time to live), measured in seconds. The TTL is the maximum time that a recursive resolver, an operating system, or a browser is allowed to keep the answer in cache before it has to ask again. Common values:

• 300 seconds (5 minutes): aggressive, used when an admin expects to change records soon.
• 3600 seconds (1 hour): a balanced default.
• 86400 seconds (24 hours): typical for stable infrastructure.
• 172800 seconds (48 hours): used for TLD and root records that almost never change.

TTL is also why a DNS change can take hours to propagate. If you set a TTL of one day and then change the record, every resolver that cached the old value is allowed to keep returning it for up to 24 hours. A common pre-migration trick is to lower the TTL to 300 seconds a day before the change, then raise it back after.

Recursive vs Iterative DNS Queries

People often conflate these two terms. They describe different roles in the same chain.

A recursive query is what your computer sends to the resolver. The client says “tell me the IP of pudgycat.io, do not come back until you have an answer or a definitive failure”. The resolver is responsible for following the chain.

An iterative query is what the resolver sends upstream to root, TLD, and authoritative servers. Each iterative query gets either a final answer or a referral to the next server. The resolver chases the chain one hop at a time, on behalf of the client. The client never sees this complexity.

This split design is what makes DNS scale. Root and TLD servers handle billions of small iterative queries, but never have to maintain a session or do the heavy work of resolving the whole chain themselves.

DNS Security: DNSSEC, DoH, and DoT

Classic DNS has two ugly properties. It is unencrypted, and it does not authenticate the answers. Three modern protocols fix different parts of the problem.

DNSSEC

DNS Security Extensions sign DNS records with public-key cryptography. A resolver that supports DNSSEC can verify that the response actually came from the authoritative server and was not modified in transit. DNSSEC does not encrypt the traffic, it only authenticates the records.

DNS over HTTPS (DoH)

DoH wraps DNS queries inside normal HTTPS requests. To an observer on the network, your DNS lookups are indistinguishable from any other web traffic. Firefox, Chrome, and most modern operating systems support DoH. Cloudflare publishes a DoH endpoint at https://cloudflare-dns.com/dns-query.

DNS over TLS (DoT)

DoT runs DNS over a dedicated TLS-encrypted channel on port 853. The encryption guarantees are the same as DoH, but the traffic is identifiable as DNS, which makes it easier for network admins to monitor or block on enterprise networks. DoT is the standard choice on Android since version 9.

If you care about your browsing privacy, encrypted DNS is one of the simpler wins available. Pair it with a strong password manager (see our guide on why your browser’s password store is not enough) and you have closed two big surveillance and security holes at once.

When DNS Breaks: Common Failure Modes

Most internet outages that look like “the whole site is down” are actually DNS problems. The site is fine, the IP is fine, but the path to the answer is broken somewhere. These are the recurring patterns.

• NXDOMAIN: the authoritative server returned “no such name”. Either the domain does not exist, or the record was deleted.
• SERVFAIL: the resolver tried to chase the chain and hit an error. Often caused by misconfigured DNSSEC.
• Stale cache: the record was changed at the authoritative server, but a resolver is still returning the old value. Wait for the TTL to expire or flush the resolver cache.
• DNS hijacking: a malicious resolver returns a wrong IP for a real domain. This is one of the attacks DoH and DNSSEC are designed to defeat.
• Resolver outage: the default ISP resolver goes down. Switching to a public resolver like 1.1.1.1 fixes it in seconds.

The 2016 Dyn attack is the textbook example of how big a DNS outage can get. A botnet of compromised IoT cameras hammered Dyn, a major DNS provider, with a 1.2 Tbps DDoS. For several hours, Twitter, Reddit, Netflix, GitHub, and Spotify were unreachable for much of the eastern United States. The services themselves were running. The chain that translated their names was not.

If you find this kind of “the internet stack is held together by hidden contracts” history interesting, our explainer on Dead Internet Theory and the piece on how video streaming actually works cover similar territory from different angles. The deep cuts on consumer hardware, like whether dark mode actually saves battery and what mechanical keyboard switches actually feel like, sit alongside this one in the same explainer family. And for a different kind of strange internet plumbing, the USB dead drop project is the offline mirror image of DNS.

Frequently Asked Questions

How long does DNS resolution take?

On a fully cached lookup, less than 1 millisecond. On a fresh lookup that traverses the full chain from root to authoritative, typically 20 to 120 milliseconds. Cold-cache lookups across the open internet rarely exceed 200 ms unless something is misconfigured.

What is the difference between a DNS resolver and a DNS server?

“DNS server” is a loose term that can mean any of the four types: recursive resolver, root, TLD, or authoritative. “DNS resolver” specifically means the recursive resolver, which is the one that talks to your client device and chases the chain on your behalf.

How do I flush my DNS cache?

On Windows, run ipconfig /flushdns. On macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On Linux with systemd-resolved, sudo resolvectl flush-caches. Browsers each have their own cache, accessible through their internal settings pages (chrome://net-internals/#dns in Chrome).

Is changing my DNS resolver legal and safe?

Yes. Pointing your device at Cloudflare 1.1.1.1 or Google 8.8.8.8 is legal everywhere and trivially reversible. Reputable public resolvers tend to be faster than ISP resolvers and often have better privacy policies. The setting lives in your network adapter properties on Windows, in System Settings, Network on macOS, or in the router admin panel if you want it for every device on the network.

Can DNS be used to block websites?

Yes, and many countries do exactly that. Most national-level web censorship is enforced at the DNS layer because it is cheap and effective. The site itself is still reachable by IP, but your resolver lies about where it lives. Encrypted DNS (DoH or DoT) and DNSSEC are the standard ways around DNS-based blocking, though both can be detected and blocked at higher layers.

The Takeaway

DNS resolution is one of those quiet internet protocols that nobody thinks about until it stops working. Eight invisible steps, four kinds of servers, a few well-chosen caches, and a forty-year-old design that still carries every URL on the planet. The next time a website loads in a fraction of a second, you will know what happened in the background. And the next time a major site goes down for no obvious reason, your first guess should probably be DNS.