Why this exists: machines on the internet find each other by numeric addresses, and humans are hopeless at remembering numbers — worse, the numbers change whenever a machine moves. The fix was one clean idea: a global lookup that turns the name you remember into the address machines need, every single time. It won because of that indirection — one big reason, at least: names stay stable while the machines behind them move freely, so the whole internet can be rearranged without anyone updating a bookmark. That lookup system is DNS, 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.
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?