How DNS Works

To understand how DNS works, picture the system that translates a name you can remember—like example.com—into the numeric address a computer actually needs to connect, all in a few milliseconds before any website loads. The Domain Name System (DNS) is the internet's distributed address book, and this guide walks through its hierarchy, the exact sequence of a lookup, the record types that power it, how caching makes it fast, and how it's secured. By the end you'll understand what happens in the silent moment between typing a URL and the page beginning to load.

What DNS is and the problem it solves

Every device on the internet is reached by an IP address—a number like 93.184.216.34 for IPv4, or a longer string like 2606:2800:220:1:248:1893:25c8:1946 for IPv6. Routers use these numbers to move data to the right place. The problem is obvious: humans can't remember numbers like that for every site they visit, and those numbers change when sites move servers.

DNS solves this by mapping memorable domain names to IP addresses. You think in names; the network runs on numbers; DNS is the translation layer between them. It's often called the internet's phone book, but a more accurate description is a distributed, hierarchical database—distributed because no single machine could hold or serve the world's billions of lookups, and hierarchical because the naming system is organized as a tree that splits responsibility across many independent operators.

That design is why DNS scales to the entire internet without a central bottleneck, and why it keeps working when individual servers fail. It's also the first thing that happens on nearly every connection you make—before HTTPS encrypts your traffic, before a page or video loads, a name has to become a number.

The DNS hierarchy: root, TLD, and authoritative servers

Read a domain name right to left and you're reading the hierarchy from top to bottom. In www.example.com, there's an invisible dot after com—the root—then the top-level domain com, then example, then the www host. Each level is handled by different servers.

The root and TLD servers

At the top sits the root zone, served by 13 root server addresses (named a through m.root-servers.net). That sounds dangerously few, but each address is anycast—replicated across many hundreds of physical servers worldwide that share the same IP, so your query reaches a nearby copy. This anycast design also makes the root resilient: it absorbs traffic spikes and distributed attacks by spreading load across continents, and losing any single instance simply routes queries to the next-nearest one. The root servers don't know where example.com lives; they only know who runs each top-level domain.

Below the root are the TLD (top-level domain) servers, responsible for a single suffix: .com, .org, country codes like .uk or .jp, and newer ones like .dev. The TLD servers for .com don't know example.com's address either—they know which servers are authoritative for it.

Authoritative servers, registries, and registrars

The authoritative nameserver is the source of truth for a specific domain. It holds the actual records and gives the definitive answer. When you "own" a domain, you (or your DNS provider) control its authoritative records.

Three roles often get confused. The registry operates a TLD and its master database (Verisign runs .com, for example). A registrar is the company that sells you a domain and registers it with the registry (Namecheap, Cloudflare, GoDaddy). And the registrant is you, the owner. The registrar is also typically where you point your domain at its authoritative nameservers.

How a DNS lookup actually works, step by step

Here's the sequence when you visit a site whose address isn't already cached anywhere. The work is done by a recursive resolver—usually run by your ISP, or a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1—which does the legwork on your behalf.

1. Your device asks its stub resolver. The operating system's built-in stub resolver checks its local cache. If the answer isn't there, it forwards the question to the configured recursive resolver.
2. The recursive resolver checks its cache. If it recently answered the same question, it returns the cached result immediately and the process ends here—which is the common case.
3. The resolver asks a root server. On a cache miss, it queries a root server: "Where is .com?" The root replies with a referral to the .com TLD servers. It doesn't answer the full question—it points one level down.
4. The resolver asks the TLD server. "Where is example.com?" The .com server replies with a referral to example.com's authoritative nameservers.
5. The resolver asks the authoritative server. "What's the address for example.com?" The authoritative server returns the actual answer—the A record with the IP address.
6. The resolver caches and replies. The recursive resolver stores the answer for the duration of its TTL (more on that below) and hands the IP back to your device, which can finally open a connection.

The key distinction: your device makes one recursive query ("get me the final answer"), while the resolver makes a series of iterative queries (root, then TLD, then authoritative), following referrals until it has the answer. You can watch this yourself with the dig command-line tool:

$ dig example.com A +short
93.184.216.34

$ dig +trace example.com    # shows the full root → TLD → authoritative walk

The whole exchange typically completes in tens of milliseconds, and far faster when cached.

The DNS records that make it work

A domain's authoritative server holds a set of resource records, each a typed entry answering a different question. These are the most common:

A few practical notes. A CNAME points one name at another rather than at an IP, which is how services tell you to point www or a subdomain at their infrastructure—and it's central to how a content delivery network routes you to a nearby edge server. TXT records are a workhorse for proving you own a domain and for email anti-spoofing (SPF, DKIM, DMARC). The CAA record quietly underpins web security by controlling which certificate authorities can issue HTTPS certificates for your domain. And one record works in reverse: the PTR record maps an IP address back to a name, the basis of reverse DNS lookups that mail servers use to gauge whether a sender is legitimate.

Caching and TTL: why DNS feels instant

If every lookup ran the full root-to-authoritative walk, DNS would be slow and the root servers would melt. Caching prevents both. Answers are stored at multiple layers—your browser, your operating system's stub resolver, and the recursive resolver—so most lookups never leave your machine or your ISP.

How long a record may be cached is set by its TTL (time to live), a value in seconds attached to each record. A TTL of 3600 means "you may reuse this answer for an hour." Short TTLs (say 300 seconds) keep records nimble for change; long TTLs (a day or more) reduce lookups and load for stable records.

TTL also explains the most common DNS misconception. People say a change is "propagating across the internet," imagining an update being pushed everywhere. That's not what happens. DNS isn't pushed—old answers simply linger in caches until their TTL expires, after which the next lookup fetches the new value. The practical lesson: lower a record's TTL a day or two before a planned change, so caches expire quickly when you cut over, then raise it again afterward. And when troubleshooting, flushing your OS or browser DNS cache clears stale local entries.

Keeping DNS secure: spoofing, DNSSEC, and encrypted DNS

DNS was designed in the early 1980s for a smaller, more trusting internet, and by default it has two weaknesses worth understanding.

The default weaknesses

Classic DNS travels as unencrypted, unauthenticated plaintext, usually over UDP on port 53. Unauthenticated means a client can't cryptographically verify that an answer truly came from the legitimate authoritative server, which opens the door to cache poisoning—tricking a resolver into storing a forged record that sends users to an attacker's server. This isn't theoretical: in 2008, security researcher Dan Kaminsky disclosed a flaw that made poisoning a resolver's cache alarmingly practical, prompting a coordinated, industry-wide patch of nearly every DNS server on the internet. Unencrypted means anyone on the network path can see which domains you look up, even if they can't read the encrypted page contents afterward.

DNSSEC: authenticating answers

DNSSEC (DNS Security Extensions) addresses the first problem. It attaches cryptographic signatures to DNS records, forming a chain of trust that runs from the root down to each domain. A validating resolver can then verify that an answer is genuine and unmodified. Crucially, DNSSEC authenticates but does not encrypt—it proves the answer is real, but doesn't hide your queries.

Encrypted DNS: DoH and DoT

Privacy is handled by encrypting the query itself. DNS over HTTPS (DoH) sends lookups inside ordinary HTTPS traffic on port 443, and DNS over TLS (DoT) uses a dedicated encrypted channel on port 853. Both stop on-path observers from seeing your lookups, and modern browsers and operating systems increasingly enable DoH by default. This is related to but distinct from the protection a VPN provides by tunneling all your traffic—and a common pitfall called a "DNS leak" happens when your device sends DNS queries outside the VPN tunnel, exposing the sites you visit even while the rest of your traffic is hidden. Using DNSSEC for integrity and encrypted DNS for privacy together closes both gaps.

Where DNS fits in the bigger picture

DNS is one quiet layer in the stack that gets you online, and it touches nearly everything else. The resolver your devices use is usually handed to them automatically by your home router—often a Wi-Fi 7 router or a mesh Wi-Fi system—via DHCP, which is why changing DNS settings at the router level affects every device on your network. Once DNS returns an address, the content delivery networks behind most large sites use clever DNS responses to send you to the closest server, which is a big part of why streaming services deliver video smoothly to millions at once. And the moment a connection opens, HTTPS takes over to encrypt it. DNS is the unglamorous first domino, and it's a good entry point into the broader picture of how modern technology works.

Frequently asked questions

What happens if DNS goes down? If the resolver you use fails, your device can't translate names to addresses, so sites appear unreachable even though the servers are fine—you may still reach them by raw IP. This is why many people configure a reliable public resolver and why operating systems cache recent answers as a buffer.

What's the difference between a recursive resolver and an authoritative server? A recursive resolver does the lookup work for you, querying other servers until it finds the answer. An authoritative nameserver is the source of truth for a specific domain and gives the definitive answer. The resolver asks; the authoritative server answers.

Why do DNS changes take time to take effect? Because of caching and TTL. Old records remain cached around the internet until their time-to-live expires; nothing is actively pushed out. Lowering the TTL before a change makes the switch take effect faster once you cut over.

Is changing my DNS resolver safe, and does it speed things up? Switching to a reputable public resolver like 1.1.1.1 or 8.8.8.8 is safe and can be slightly faster than a slow ISP resolver, and many support encrypted DNS for privacy. The speed gain is usually modest, since most lookups are already cached.

Does DNS encrypt my browsing? By itself, no. Classic DNS is plaintext. DNSSEC authenticates answers but doesn't encrypt them, while DNS over HTTPS or DNS over TLS encrypts the lookup. Encrypting the page content itself is the job of HTTPS, a separate layer.

The takeaway

Now that you understand how DNS works, the core idea is simple: a hierarchical, cached, distributed system quietly turns the names you type into the addresses machines need, usually in milliseconds and usually invisibly. The next time a site won't load, you'll know to suspect the resolution step—try a lookup with dig or nslookup, or switch to a public resolver, before assuming the site itself is down. DNS is the foundation everything else on the web is built on, and seeing it clearly makes the rest of the internet's plumbing far easier to understand.