DNS: How the Internet Finds Any Website

The problem

Here's the problem. People remember names, like google.com. But the network delivers packets to IP addresses, which are numbers. Something has to translate one into the other.

That's DNS, the Domain Name System. Think of it as the internet's phonebook. But no single computer could hold every name in the world, so the phonebook is split up and spread across thousands of servers.

The trick is that names are a hierarchy. Read them from right to left. There's an invisible dot at the end: the root. Then the top-level domain, .com. Then the domain, google. Then the subdomain, www.

www . google . com .

.          root
com        top-level domain (TLD)
google     domain
www        subdomain

Step 1 · Caches

When you type a name, nobody goes to the internet straight away. First the browser checks its own cache. Then it asks the operating system, which has its own cache, and also checks a local file called hosts.

Step 2 · Resolver

If nobody nearby knows, the question goes to a recursive resolver. Usually it's run by your internet provider, or a public one like Google's 8.8.8.8, or Cloudflare's 1.1.1.1.

The resolver does all the legwork for you. If it has the answer cached, it replies at once. If not, it walks the hierarchy, starting from the top.

Step 3 · Root

First stop: a root server. It doesn't know google.com, but it knows who runs every top-level domain. It replies: I don't know, but ask the.com servers, and here are their addresses.

There are thirteen named root servers, lettered a to m. But each name is really hundreds of machines around the world, sharing one address through a technique called anycast. You reach whichever is closest.

Step 4 · TLD

Next, a.com server. It doesn't know the address either, but it knows which name servers are in charge of google.com. It replies with those.

Step 5 · Authoritative

Finally, the authoritative name server for google.com. This one holds the real records, set by Google. It answers: here's the IP address.

Step 6 · Answer

The resolver hands the address back to your computer, and everyone along the way caches it: the resolver, the operating system, and the browser. The whole walk took maybe twenty to a hundred milliseconds.

Now the browser finally knows where to go, and it can open a connection to the website.

Two kinds of query

Notice the two kinds of questions. Your computer asks the resolver a recursive query: give me the final answer. The resolver asks the others iterative queries: who should I ask next? This is a classic interview question.

Caching & TTL

Caching only works if answers expire. Every DNS record carries a TTL, time to live, in seconds. A short TTL means changes spread quickly. A long TTL means fewer lookups and faster browsing. That's the trade-off.

google.com.  300  IN  A  142.250.x.x
             ^^^
             cache for 300 seconds

short TTL → changes spread fast
long TTL  → fewer lookups

Record types

DNS holds more than addresses. An A record maps a name to an IPv4 address, and AAAA to IPv6. A CNAME points one name at another name. MX says where to deliver email. NS lists the authoritative servers. And TXT holds text, used for things like proving you own a domain.

A      name → IPv4 address
AAAA   name → IPv6 address
CNAME  name → another name
MX     where to deliver email
NS     the authoritative servers
TXT    text: verification, SPF

DNS in system design

In system design, DNS does more than lookups. It can return different IP addresses to different users. That's how traffic gets spread across data centres, and how users are sent to the region closest to them.

Round-robin DNS rotates through several addresses. Geo DNS answers based on where you are. Failover removes an address when its server is down. The catch: caches keep old answers until the TTL runs out, so DNS alone reacts slowly.

Security

Classic DNS has no built-in protection. An attacker who sneaks a fake answer into a cache can send users to the wrong server. That's called DNS spoofing, or cache poisoning.

The defences: DNSSEC signs records so resolvers can reject fakes. And DNS over HTTPS, or over TLS, encrypts the lookups so nobody on the network can read or change them.