Why this exists: machines find each other by numeric addresses, and humans cannot remember numbers that change whenever a machine moves. DNS is the lookup that turns the name you remember into the address machines need. Names stay stable while the machines behind them move, and it runs before every connection you ever make.

What DNS actually does

You type cloudcaive.com. Half a second later the right page appears from a computer somewhere on Earth. In between, DNS (the Domain Name System) did one job: it looked up the IP address — the computer's number, something like 104.21.40.121 — for the name you typed, so your browser knew where to connect. Name in, address out: a phone book for the whole internet, run by many connected computers rather than one company. No DNS answer, no connection — it is step one of everything.

The wrong ideas people start with

Three tempting misunderstandings, each worth clearing up once. DNS does not fetch the page — downloading happens afterwards, when your browser contacts the address DNS returned. It does not approve or safety-check websites — some DNS services add blocking on top, but the basic job is lookup, not judgement. And it is not a company that owns names — companies called registrars sell names, while many organisations run the lookup computers that answer where those names lead.

How a lookup flows

Your device asks a resolver — a lookup helper, usually run by your internet provider. The resolver walks the chain: the root servers, then the .com servers, then the domain's own authoritative servers — the ones holding the actual answer. Then it caches the result: keeps a copy so the next lookup is instant. Caching is why DNS feels fast, and why changes take time to "propagate" — old answers live in caches until their TTL (time-to-live, an expiry timer on each answer) runs out.

A DNS lookup, uncached and cached First lookup: your device asks the resolver, which asks the root servers, then the .com servers, then cloudcaive.com's authoritative servers, and returns the address with a 300-second time-to-live. Second lookup within that time: the resolver answers from its cache without asking anyone. FIRST LOOKUP · NOTHING CACHED · FOUR QUESTIONS Your devicecloudcaive.com? ResolverISP or 1.1.1.1 Root→ ask .com .com→ ask domain Authoritativehas the answer answer: 104.21.40.121 · keep for 300 s (the TTL) SECOND LOOKUP · WITHIN 300 SECONDS · ANSWERED FROM CACHE Your devicecloudcaive.com? Resolvercached · 212 s left ROOT · .COM · AUTHORITATIVE — NOT ASKED 104.21.40.121 (from cache) WHY CHANGES TAKE TIME If the address changes, every resolver keeps handing out the old answer until its copy expires. That wait, up to one TTL per cache, is what people call “propagation”.
Uncached, then cached. The first lookup walks the chain; the next one, inside the answer's time-to-live, is served by the resolver alone. Both are the same one-line question: which address does this name point to?

Where you'll meet this on the job

DNS records are configuration you will manage: A records point a name at an address, CNAME points a name at another name, MX routes mail, TXT holds verification text. A mistyped record takes a service offline in ways that look baffling — the server is fine, yet nobody can reach it — which is why engineers joke, with a grain of truth, that "it's always DNS." When a site seems down but the machine is healthy, checking name resolution comes early in the checklist:

dig cloudcaive.com        # full lookup detail
nslookup cloudcaive.com   # quick answer

Both run in the terminal you already know — and both answer the only question that matters at step one: does this name still point where it should?

After this, you can: explain what DNS does in one sentence, spot the three classic misunderstandings, and run the two commands that check whether a name resolves.