How DNS Works: The Domain Name System, Explained

Most DNS queries never actually happen. A large share are answered straight from a cache inside your own browser, and most of the rest die quietly inside your ISP without ever crossing the wider internet. Behind that quiet, a system sketched out in the 1980s keeps coordinating trillions of lookups a day, turning names into addresses in a few milliseconds.

You lean on it every time you open a tab, and you have probably never thought about how it works. This guide walks through what DNS is, why it exists, the exact path a lookup takes, the records and servers involved, how caching makes it fast, and the security and failure stories that make engineers wince.

What is DNS?

DNS, the Domain Name System, is the service that translates a human-readable domain name like github.com into the numeric IP address a computer needs to connect, such as 140.82.121.4. Without it you would have to memorize a string of numbers for every site you visit. DNS is the lookup layer that lets you remember names instead.

It is usually called the phone book of the internet, and that gets the idea across. The comparison undersells it though. A phone book is one static list, while DNS is a live, hierarchical system spread across thousands of servers, answering an enormous volume of queries every second and updating as the internet changes.

Why DNS exists: the file that didn’t scale

Computers never cared about names. They route packets using IP addresses, and a name like google.com means nothing to them. DNS exists to bridge that gap, because expecting people to recall something like 142.250.74.14 for every site was never going to work.

The first fix was almost comically simple: a single text file. In the early ARPANET, every machine was listed in one shared file called HOSTS.TXT, maintained at the Stanford Research Institute. If you wanted to add a host, you contacted Stanford, they edited the file, and every other machine downloaded the new copy. It held up while the network had a few hundred hosts.

Then it buckled. The file grew with every host, updates always lagged reality, names collided, and one organization controlled the entire namespace. So in 1983 a new design replaced it, built on one idea: delegation. Instead of one master file, you split the namespace into zones and let different organizations run different parts. That distributed system still runs the internet today.

How does DNS work? The lookup, step by step

A DNS lookup resolves a name by checking caches first, then handing the work to a recursive resolver that walks the hierarchy from the top down. Your device asks one question and gets one answer. The resolver, behind the scenes, may ask several servers in turn before it can reply. Most of the time it never gets that far, because a cache already has the answer.

Say you type www.example.com. Your browser checks its own cache first. Miss, and the request goes to your operating system’s stub resolver, which checks the OS cache. Miss again, and the query goes out to a recursive resolver, usually your ISP’s or a public one like 8.8.8.8 or 1.1.1.1. That resolver is where the real work starts.

01

Browser cache Already knows the IP? Done. No network call.

02

OS stub resolver Your system’s built-in DNS client checks its cache.

cache miss ↓

03 · Recursive resolver

Your ISP’s DNS, or a public one like 8.8.8.8 or 1.1.1.1. Your device makes one recursive query and the resolver takes over, chasing the answer down the hierarchy.

1. 1
   Root nameserver “Who handles .com?” Referral to the .com servers.
2. 2
   TLD nameserver “Who handles example.com?” The domain’s authoritative nameservers.
3. 3
   Authoritative nameserver “What’s the A record for www?” The IP. The source of truth answers.

Result cached at every layer on the way back, then handed to the browser. Typically under 100 ms cold, near-zero warm.

The resolver asks a root server who handles .com, gets pointed at the .com servers, asks them who handles example.com, gets pointed at the domain’s own nameservers, and finally asks those for the actual record. This split has names: your device makes a single recursive query (give me the final answer), and the resolver makes several iterative queries (each server hands back the best it has, usually a pointer to the next one). The resolver caches the result, passes it back, and only now does your browser open a connection. Cold, the whole trip is typically under 100 ms.

What is a DNS server?

A DNS server is any machine that takes part in answering lookups, and there are four distinct roles. They are not four flavors of the same box, they are different jobs in a chain: the recursive resolver that does your legwork, and the three authoritative tiers (root, TLD, and the domain’s own server) that each know one slice of the map. No single server holds the whole thing.

The recursive resolver is the one your device talks to. It is the legwork machine, and it is also where caching pays off most, since it serves millions of users at once. The root servers sit at the top and know only which servers run each top-level domain. The TLD servers (for .com, .org, .io, and the rest) know which nameservers run each domain under them. The authoritative server holds the domain’s real records and is the source of truth.

Root 13 server identities · the “.” at the end

.com TLD registry operator .org TLD registry operator .io TLD registry operator

example.com authoritative nameserver · the source of truth

There are 13 root server identities, named a through m, run by 12 independent organizations. That number is a quirk of a 1980s packet-size limit, not a count of physical machines. Through a routing trick called anycast, those 13 addresses are actually served by well over a thousand real servers worldwide, so a query reaches a nearby one. Above all of them sits a huge namespace: Verisign’s industry brief tracks more than 380 million registered domains.

Why is DNS so fast? Caching and TTL

DNS is fast because it caches aggressively at every layer, so the vast majority of lookups are answered close to you and never reach an authoritative server. Your browser caches answers. So does your OS, your router, and the recursive resolver that fronts millions of users. Each layer is another chance to skip the rest of the trip.

The scale this unlocks is hard to picture. Cloudflare’s 1.1.1.1 resolver alone handles about 1.9 trillion queries a day, and a cached answer from a nearby resolver typically comes back in around 7 ms, faster than you can blink. Almost none of that touches the authoritative servers at the bottom, which is the whole point.

1. 1 Browser cache Satisfies a big share of lookups on its own
2. 2 OS cache Shared across every app on your device
3. 3 Router cache Covers every device on the network
4. 4 Recursive resolver One cache serving millions of users

Authoritative server Only sees the tiny fraction of queries every cache above missed.

TTL

Every record carries a timer in seconds. Short TTL means faster changes, more load. Long TTL means better performance, slower changes. Nothing “propagates” when you edit a record, you’re just waiting for these timers to expire.

What keeps a cache honest is TTL, the time-to-live value stamped on every record. It tells caches how many seconds they may reuse an answer before checking again. Short TTLs let you change records quickly but add load. Long TTLs cut load and speed up repeat visits but make changes slow to show up.

The DNS record types you’ll actually touch

DNS is not only about IP lookups. A zone holds several record types, and a handful of them cover almost everything a developer does day to day. The table below is the short list worth knowing, with what each one is for.

The quiet workhorse is TXT. It looks like a junk drawer, but it holds the records that decide whether your email lands in inboxes or in spam. SPF, DKIM, and DMARC all live in TXT records, and together they let receiving servers confirm a message really came from your domain. Get them wrong and your mail silently fails. The blunt version: if DNS breaks, email breaks, sites break, almost everything breaks.

Is DNS secure?

DNS was not built to be secure. It came from a small, trusting academic network, so for years a resolver simply believed whatever answer came back. That trust is what made cache poisoning possible, where an attacker slips a forged record into a resolver so users get sent to the wrong address. The 2008 Kaminsky attack showed how alarmingly easy that was and kicked off serious work on hardening DNS.

Two separate fixes followed, and they solve two different problems that people often confuse. DNSSEC handles authenticity, and encrypted transport handles privacy. You can run both, and they do not overlap.

DNSSEC Integrity

Adds cryptographic signatures, so a resolver can verify a response really came from the authoritative source and was not tampered with. Counters cache poisoning.

Does not hide the query.

DoH / DoT Confidentiality

DNS over HTTPS or TLS encrypts the lookup itself, hiding which sites you’re resolving from networks in between. DoH rides port 443 and blends with normal web traffic.

Does not prove authenticity.

DNSSEC adds cryptographic signatures so a resolver can verify a record really came from the authoritative source. It proves integrity, but it does not hide anything, and adoption is still patchy: APNIC’s measurements put the share of users behind validating resolvers at roughly a third. For privacy you want DoH or DoT, which encrypt the query itself so networks in between cannot read it. There is also a nastier class of abuse: DNS amplification, where attackers bounce small queries off open resolvers to flood a victim with huge responses. DNS is critical infrastructure, which makes it a tempting target.

DNS is no longer just a phone book

Modern DNS does far more than name lookups. Cloud providers turned it into a routing control plane, where the answer you get depends on who and where you are. You can send European users to an EU region, shift a slice of traffic to a new cluster, or fail over to another region the moment a health check goes red, all through DNS.

It is also how clusters find themselves. In Kubernetes, DNS is service discovery: pod IP addresses come and go constantly, so every service gets a stable DNS name and the IPs underneath stay invisible. Even your home network can bend DNS to its will, the way Pi-hole blocks ads by resolving known ad domains to nowhere. The phone book grew into infrastructure logic.

Why engineers say “it’s always DNS”

There is a running joke in operations that whatever just broke, it’s always DNS. It endures because the pattern is real and the blast radius is enormous. The instructive part is that the biggest DNS failures were not break-ins. They were ordinary configuration mistakes that happened to land on a system everything else depends on.

2016 Dyn

A botnet of hacked IoT devices (cameras, DVRs) flooded the managed DNS provider Dyn.

Twitter, Netflix, Reddit, Spotify down for hours

2021 Facebook

A bad BGP change withdrew the routes to Facebook’s own DNS servers. They vanished from the internet.

Facebook, Instagram, WhatsApp gone 6+ hours

2025 Cloudflare 1.1.1.1

A dormant config error withdrew the BGP routes for 1.1.1.1 when an unrelated change shipped.

Total DNS failure for 1.1.1.1 users for 62 min

In 2016, a botnet of hacked smart-home gadgets overwhelmed the DNS provider Dyn and pulled Twitter, Netflix, and Reddit down for hours. In 2021, Facebook vanished from the internet for six hours when a bad network change made its own DNS servers unreachable. And in July 2025, a dormant config error at Cloudflare withdrew the routes for 1.1.1.1, and anyone relying on it lost DNS entirely for 62 minutes. DNS rarely fails. When it does, everything stacked on top of it falls with it.

So, do you need to understand DNS?

If you build, ship, or debug anything on the web, yes. DNS sits underneath your site, your email, your deploys, and your incident postmortems, and a working mental model of it turns a baffling outage into an obvious one. You do not need to memorize record syntax. You need to know that names map to addresses, that caching and TTL explain most of the weird timing, and that “it’s not resolving” is a real and common failure.

The surface of DNS is simple. Type a name, get an address. Underneath is a globally distributed system, stitched together by delegation, layered with caches, and hardened over decades of failures. Most of the time you never notice it, right up until you do.

For the animated version of all of this, the lookup, the caching, and the real outages in about nine minutes, watch the full explainer on YouTube.