Computers on the internet find each other by number, not by name. When you type example.com into a browser, something has to turn that friendly name into a number like 192.0.2.10 before a single byte of the web page can travel. That something is DNS, the Domain Name System. It's the internet's phone book, except no single computer holds the whole book. This page follows one lookup from your keyboard to the answer, and shows why most lookups take almost no time at all.

Names for people, numbers for machines

Every device on the internet is reached through an IP address (IP stands for Internet Protocol). The older and still most common kind, IPv4, is four numbers from 0 to 255 separated by dots, like 203.0.113.7. The newer kind, IPv6, is longer and written in hexadecimal, like 2001:db8::7. Routers, the machines that pass your data along, only understand these numbers.

Numbers are terrible for people, though. They're hard to remember, and they change: a company might move its website to a new server or a new hosting provider, and the address changes with it. So we use domain names instead, and DNS keeps the mapping between the two up to date. You remember the name; DNS remembers the number.

Reading a name from right to left

A domain name is a list of labels separated by dots. People read it left to right, but DNS reads it right to left, from the most general part to the most specific:

• The root. There's an invisible, empty label at the far right. The fully written name is really www.example.com. with a final dot. Browsers hide it, but it's always there, and it's where every lookup starts.
• The top-level domain (TLD). The last visible label: com, org, nl, uk, dev and over a thousand others.
• The domain name you register. example in example.com. Together with the TLD, this is the part someone buys from a registrar (a company that sells domain names).
• Subdomains. Anything further left, like www, mail or api.dev. The owner of the domain can create as many as they like, for free.

A full web address (a URL) has more in it than the name, and that's a common source of confusion. Type any URL below and watch it split into parts. Notice which part DNS actually cares about.

Two things to take from the splitter. First, DNS only ever sees the hostname: the scheme (https://), the port (:8080), the path (/blog/post) and the query (?id=7) are used later, by your browser and the web server. Second, some countries use two-label endings like co.uk: you can't register co.uk itself, so in shop.example.co.uk the name you'd buy is example.co.uk. The splitter knows a handful of these; browsers use a long shared list called the Public Suffix List.

The cast: who takes part in a lookup

No single server knows every name on the internet. Instead, the work is split between several kinds of DNS servers, each knowing a small piece and pointing to whoever knows the next piece.

• Your browser and operating system. Both keep a small memory, called a cache, of names they looked up recently. The operating system (Windows, macOS, Linux, Android…) also checks a little local file called the hosts file, where you can pin a name to an address by hand. The part of your OS that asks DNS questions is called the stub resolver: it doesn't do the hard work itself, it just asks someone else.
• The recursive resolver. That "someone else". Usually it's run by your internet provider and your home router hands its address to your devices automatically. You can also choose a public one, such as Cloudflare's 1.1.1.1, Google's 8.8.8.8 or Quad9's 9.9.9.9. It's called recursive because it keeps asking around, on your behalf, until it has a final answer.
• The root servers. The top of the tree. There are 13 root server names, a.root-servers.net to m.root-servers.net, run by 12 different organisations. Each name is backed by many copies spread across the world, well over a thousand machines in total, so you're always talking to a nearby one. The root doesn't know where example.com is. It only knows who runs each TLD.
• The TLD servers. One set per ending: the .com servers know which name servers are responsible for every .com domain, but not the final addresses.
• The authoritative name servers. The servers chosen by the domain's owner (often their hosting or DNS provider). These hold the real records for example.com and give the final, authoritative answer.

The root and TLD servers don't answer the question. They give a referral: "I don't know, but ask these servers". The resolver follows the referrals down the tree until it reaches someone who knows. Step through a lookup for www.example.com and switch between the cache situations to see how many trips it takes.

With nothing cached, the resolver makes three separate trips (root, .com, authoritative), plus the trip from your computer to the resolver: four round trips in total, each typically taking somewhere between a few and a hundred-odd milliseconds. With the answer already cached, it's one trip, or zero if your browser remembers. That's the whole trick that keeps DNS fast: almost every lookup is answered from a cache somewhere along the way, and the root servers hear about only a tiny share of the world's lookups.

Records: what the answer actually looks like

An authoritative server stores records: small facts about a name. Each record has a name, a type, a value and a TTL (more on that in a moment). The ones you'll meet first:

You can ask DNS yourself from a terminal. On macOS and Linux, the dig tool shows the raw answer; nslookup example.com works on Windows too. An answer line looks like this (illustrative, with a documentation address):

$ dig +noall +answer www.example.com
www.example.com.     3600    IN    A    192.0.2.10

Read it left to right: the name (with its final root dot), the TTL in seconds (3600 = one hour), the class (IN for "internet", almost always), the record type (A), and the address. Run it twice against a caching resolver and the TTL number goes down between runs: you're seeing the cached copy count down.

TTL: how long a cache may remember

Caching makes DNS fast, but it raises a question: if the resolver remembers the answer, how does it ever notice when the address changes? The answer is the TTL, short for time to live. Every record carries one, set by the domain's owner. It says "you may reuse this answer for this many seconds, then you must ask again". When it runs out, the cached copy expires and the next visitor's lookup goes all the way back to the authoritative server.

Choosing a TTL is a trade-off. Below, visitors who share one resolver ask for www.example.com every 5 minutes. The first visitor, at minute 0, makes the resolver fetch and cache the address 192.0.2.10. One minute later the owner moves the site to a new server and changes the A record to 203.0.113.20. Drag the TTL and watch which visitors still get sent to the old, switched-off server.

A long TTL means fewer lookups and faster answers, but changes take longer to reach everyone. A short TTL means changes spread quickly, at the cost of more lookups. Common settings range from 5 minutes to a day. A trick professionals use: a day or two before moving a site, they lower the TTL to a few minutes, wait for the old long TTL to run out everywhere, make the change, then raise the TTL again afterwards.

When DNS goes wrong

Because almost everything online starts with a name lookup, a DNS problem looks like "the internet is broken" even when the network is fine. Some things you might see:

• "This site can't be reached" / DNS_PROBE_FINISHED_NXDOMAIN in Chrome. NXDOMAIN means "non-existent domain": the authoritative servers said this name doesn't exist. Usually a typo, or a domain that has expired.
• The old version of a site keeps showing up after a move. A cache somewhere is still within its TTL. Wait, or clear your own caches (restarting the browser helps; each OS also has a "flush DNS" command).
• Everything fails, but typing an IP address works. Your resolver is down or unreachable. Switching to a public resolver usually fixes it.
• A name points somewhere surprising on one computer only. Check the hosts file: developers often add lines like 127.0.0.1 myapp.test there and forget about them.

One more thing worth knowing: classic DNS messages travel unencrypted (on port 53, mostly over UDP, a quick no-handshake way to send small messages), so anyone on the network path can see which names you look up. Newer options like DNS over HTTPS wrap the same questions in encryption, and many browsers can turn it on in their settings.

Check yourself

The short version

• DNS turns names like www.example.com into IP addresses that routers understand.
• Names are read right to left: root (the hidden final dot), then the TLD (com), then the registered name (example), then subdomains (www). DNS only sees the hostname, never the path.
• Your recursive resolver does the legwork, following referrals from the root servers to the TLD servers to the domain's authoritative servers.
• Answers are cached in your browser, your OS and the resolver, so most lookups take one trip or none.
• The TTL on each record says how many seconds a cache may keep it. Long TTL: fast and cheap. Short TTL: changes spread quickly.

Next time a page takes a moment to start loading on a site you've never visited, you'll know part of that pause was a little relay race across the internet, just to find out where to go.