Skip to content

How DNS Works

Task: Follow one name from your browser to an IP address

Browseryoutube.com142.250.183.14DNS resolverCACHEDRoot serverknows who handles .com.com TLD serverknows who handles youtube.comAuthoritative serverknows the IP address

Why we need DNS

Analogy

  • Imagine you want to send a letter to Ashu. You know Ashu's name, but the post office needs their exact address.
  • The internet has the same problem. You type youtube.com, but computers do not talk to each other using names.
  • They use IP addresses, like 142.250.183.14.
  • So something has to turn the name into the address. That something is DNS.

What is DNS?

Definition

DNS, the Domain Name System, translates a domain name into an IP address.

youtube.com becomes 142.250.183.14.

Think of your phone's contacts. You tap Mom and your phone finds the number. Your browser asks DNS "where is youtube.com?" and DNS answers with an address.

WHAT YOU KNOWWHAT THE MACHINE NEEDSMomContacts+91 98xxxyoutube.comDNS142.250.183.14

Note

DNS does not load the website. It only tells your computer where the website lives. Fetching the page is a separate job that happens after.

What happens when you type a website?

You type google.com. Your browser needs Google's IP address before it can ask for anything at all, so the request roughly follows this path:

browser → DNS → IP address → Google's server

Once the browser has the address, it can open a connection and ask for the page.

But who does DNS ask?

Here is the part that surprises people. There is no single giant DNS server holding every domain in the world. DNS is distributed, and a lookup steps through several levels.

Your deviceknows the name you typedDNS resolverdoes the asking, and remembers the answerRoot serverknows who handles .com.com TLD serverknows who handles youtube.comAuthoritative serverholds the record, and answers142.250.183.14the address your browser needed

Each level only knows enough to point at the next one.

Finding youtube.com, step by step

Suppose the resolver does not already know the answer. It asks the root server: who handles .com?

The root does not know where youtube.com is. It only answers: ask the .com servers.

So the resolver asks the .com TLD server: who handles youtube.com? That server points at YouTube's authoritative server, the one actually responsible for the name.

Finally the resolver asks that server for the address, and this time it gets one.

Three questions, and none of them returned an address until the last. The animation at the top of this page walks exactly that path, one hop at a time.

Why not do this every time?

Imagine looking up Ashu's address every single time you wanted to post them a letter. Wasteful.

So DNS caches. Once a resolver learns that youtube.com is at 142.250.183.14, it holds on to that for a while. The next person who asks gets an answer immediately.

FIRST TIMETHREE HOPSRoot.com TLDAuthoritativeIPNEXT TIMENO HOPSanswered straight from the resolver’s cacheIP

Watch out

A cached answer does not live forever. Every record carries a TTL, or time to live, which says how long it may be reused. When the TTL runs out the resolver has to walk the chain again, which is what lets a site move to a new server and have the world find it.

Where the pieces fit

PartWhat it does
ResolverDoes the asking on your behalf, and caches what it learns
Root serverPoints at the servers for a top-level domain like .com
TLD serverPoints at the server responsible for one name
Authoritative serverHolds the record, and gives the address

Quick recap

Whenever you see google.com, think: that is a human-friendly name, and the computer needs an address.

  • A domain name goes in
  • DNS finds the address
  • The browser gets an IP address back
  • It connects to that server
  • The page loads

Key takeaway

DNS turns human-friendly domain names into IP addresses, so computers can find each other.