Finally figuring out DNS and domain names

Thu, 28 May 2026 00:00:00 +0000

One reason why I wanted to have a public personal website, (other than sharing thoughts and doing the opposite of gatekeeping), is to show it off, as some sort of portfolio: The things I learned over the years and the things I can do.

Now as a network engineer, or as any kind of engineer who works with the internet, having the right domain name was a big deal. You can say alot from the domain name of a website. I just couldn’t bring myself to have a generic one. Now of course setting up a creative domain name is important, but I believe that knowing how to set it up matters even more.

And to set it you obviously need to know how it works. For the longest time, I knew some details about the functioning of this service but I feel like I never fully grasped the concept, so yay to a new learning opportunity :

Computers don’t speak in names

Every device connected to the internet has a numeric address called an IP address: something like 192.0.2.45 (or a longer one like 2001:db8::1 for the newer IPv6 system). That number is how machines actually find each other. It’s the equivalent of a street address: precise, but not something you’d want to memorize for every place you visit.

Humans are bad at remembering numbers and great at remembering names. So we invented a friendlier layer on top: the domain name. example.com is just a human-readable label that points to an IP address. The name is for you; the number is for the machines.

The problem is obvious: when you type a name, something has to translate it into the number. That something is DNS.

DNS: the internet’s phone book

DNS stands for the Domain Name System, and the classic way to describe it is as the internet’s phone book. You know a person’s name; you look them up to get their phone number. You know a website’s name; DNS looks it up to get its IP address.

Except there’s no single giant phone book sitting on one computer somewhere. It would be too big, too slow, and a single point of failure for the entire internet. Instead, DNS is distributed: the information is spread across a hierarchy of servers around the world, each responsible for one small piece. When you make a request, those pieces get assembled on the fly.

Here’s the relay race that happens when you visit a site for the first time.

The journey of a single lookup

Imagine you type choumicha.ma looking for a quick recipe. Your computer needs the IP address, and it asks a series of helpers:

The resolver. Your request first goes to a DNS resolver, usually run by your internet provider (or a public one like Cloudflare’s 1.1.1.1). Think of the resolver as a helpful librarian who does all the legwork for you. It doesn’t know the answer yet, but it knows who to ask.
The root servers. The resolver starts at the top. It asks a root server: “Where do I find things ending in .ma?” The root server doesn’t know choumicha.ma specifically, but it knows who manages the entire .ma neighborhood, and points the resolver there.
The TLD servers. .com is a top-level domain (TLD) — the last part of the address. Other TLDs include .org, .net, and country codes like .pl or our beloved .ma. The resolver asks the .ma server: “Who’s in charge of choumicha.ma?” The .ma server replies with the address of that domain’s authoritative servers.
The authoritative server. This is the final stop — the server that holds the real, official records for choumicha.ma. The resolver asks, “What’s the IP address?” and this server gives the definitive answer: 192.0.2.45. The resolver hands that number back to your browser, your browser connects to that IP, and the page loads.

It sounds like a lot, but it usually finishes in milliseconds. And it gets even faster after the first visit, thanks to caching: the resolver (and your own computer) remembers the answer for a while, so it doesn’t have to run the whole race every single time. How long it remembers is controlled by a setting called TTL (time to live), measured in seconds.

The records that make it all work

The “official records” stored on that authoritative server are called DNS records. Each one is a small instruction. You don’t need to know all of them, but a handful cover almost everything you’ll ever do:

A record — points a domain to an IPv4 address (the 192.0.2.45 kind). This is the most common record. “example.com lives at this number.”
AAAA record — the same idea, but for the newer IPv6 addresses. (Yes, four A’s.)
CNAME record — points one name at another name instead of an IP. Useful for saying “www.fluka.com is just an alias for flukamolsluka.com.” Whatever the target resolves to, the alias follows.
MX record — tells the world which server handles email for your domain. Without it, mail sent to you@example.com has nowhere to go.

Setting up your own domain, step by step

Now the practical part. Going from “I want a website” to “my domain points to it” is really three steps.

Step 1: Register the name

You buy a domain through a registrar: a company accredited to sell domain names (popular ones include Cloudflare, Namecheap…). You’re not really buying the name forever; you’re renting it, usually a year at a time. As long as you keep renewing, it’s yours. Registering simply records, in the global system, that this name belongs to you.

Step 2: Decide who runs your DNS

This is the step people find most confusing, so here’s the key idea: your registrar and your DNS host don’t have to be the same company.

When you register a domain, the registrar sets its nameservers: records that say “go here for the real answers.” By default they point at the registrar’s own DNS service, which is usually fine. But you can change them to point at a different provider (for example, putting your domain on Cloudflare so you can use its network and dashboard). Changing nameservers is like telling the post office which branch holds your mail forwarding instructions. It’s the highest-level switch, and everything below it follows.

So you have two valid paths:

Keep it simple: manage your DNS records right in your registrar’s dashboard.
Move your DNS elsewhere: update the nameservers to your chosen DNS provider, then manage records there. Either way, the next step is the same.

Step 3: Add the records that point to your site

Now you tell DNS where your website actually lives. If your host gave you an IP address, you create an A record pointing your domain at it. If your host gave you a name to point at instead (common with platforms like Cloudflare Pages, Netlify, or GitHub Pages), you create a CNAME pointing at that name.

A typical setup for a small site looks like this:

An A record (or CNAME) for yourdomain.com → your host.
A CNAME for www.yourdomain.com → yourdomain.com, so both the bare name and the www. version work.
An MX record and some TXT records if you’re setting up email. And here’s the beautiful part: subdomains are free and unlimited. Want blog.yourdomain.com or shop.yourdomain.com? Each is just another record under the same domain, pointing wherever you like — even at completely different services. You own the entire namespace.

Step 4: Wait for propagation

After you save a record, it isn’t always visible everywhere on Earth instantly. Because of all that caching we mentioned, resolvers around the world may still be holding old information until its TTL expires. This delay is called propagation, and it can take anywhere from a few minutes to a day, though it’s usually quick. If your new site isn’t loading right away, this is almost always why — patience, not a mistake.

Putting it all together

Step back and the whole system is elegant. A domain name is a human-friendly label. DNS is the distributed lookup system that translates that label into the numeric address machines use. Records are the individual instructions, nameservers decide who’s in charge of those records, and a registrar is just where you rent the name in the first place.

Setting up a domain, then, is really just: rent the name, decide who manages its DNS, and add a couple of records pointing at wherever your site lives. The first time you do it, the propagation wait makes it feel uncertain. By the second or third time, it’s a five-minute job — and you’ll understand exactly what every switch does.

Dns on Fluka ~$_