how/network

How DNS turns a name into an IP

The browser wants example.com, but the internet only understands IP addresses. Someone has to turn the name into a number, and a hierarchy of servers does it.

You type example.com into the browser and see a page. But the internet works by IP addresses, not by names. Somewhere in the middle the name example.com became a number like 93.184.216.34. Who did that?

DNS (Domain Name System) did it: the big global "phone book" of the internet. It is built in a clever way, though: no one stores the whole book. The address of each name is known to only one specific server, but we do not know which one. So DNS works through a hierarchy of servers that we query in turn, from general to specific.

Press ▶ and watch how one request, "give me the IP for example.com", unfolds into four network round trips and why the second time the answer comes back instantly.

step 1/6·00 · the app wants example.com

§ steps

The browser opens a connection. To know where to go, it needs an IP. The stack checks "who is our resolver?" (the address usually arrived via DHCP) and is about to send it a DNS query on UDP/53.

The local resolver is either a service in your OS (systemd-resolved on Linux) or a separate server (1.1.1.1, 8.8.8.8, a corporate one).

recap

What to remember:

Your machine usually has a local resolver: a service that does all the work for you. One request to it is enough. It goes to root, to the TLD, to the authority itself, and returns the answer
You usually get the resolver's address from DHCP options. You can check /etc/resolv.conf (the classic) or resolvectl status (systemd-resolved). Popular public ones: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare)
Every answer is cached for its TTL (the record's lifetime). Within the TTL no network requests happen at all: the answer comes straight from the local cache. That is why a site opens faster the second time
DNS runs over UDP on port 53 (see port). For large answers and encrypted DNS (DoT/DoH), TCP/853 or HTTPS is used
If DNS is broken, sites "won't open" even though a ping by IP works. The classic symptom: ping google.com hangs while ping 8.8.8.8 responds

If you want to get hands-on with DNS, there is the intermediate-04-dns lesson with the dig command and packet sniffing. And the dns-resolution article in the knowledge base with the detailed packet structure.

§ dig into the knowledge base

§ try it hands-on

intermediate-04-dns- DNS - try it by hand with dig and tcpdump

§ steps

The browser opens a connection. To know where to go, it needs an IP. The stack checks "who is our resolver?" (the address usually arrived via DHCP) and is about to send it a DNS query on UDP/53.

The local resolver is either a service in your OS (systemd-resolved on Linux) or a separate server (1.1.1.1, 8.8.8.8, a corporate one).