Fluka ~$_

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.

Yu-gi-oh inspired me to make this website

Wed, 06 May 2026 00:00:00 +0000

I finally decided it’s time to make another portfolio to display my work. This is the third one, and hopefully this one sticks. I got to admit, there is something both scary and charming about comebacks, that idea in itself deserves a discussion on its own. For now, I am sharing the system behind this website, and I think it’s worth talking about.

The Problem

I already tried this a couple of times before, and it obviously didn’t work because here we are again. For me, this website is a medium to share ideas and projects, a tool to help me track the things I’m working towards. Some sort of building in public, we do love to do that these days.

The problem I faced all these past times is that this website felt less like a tool for presenting and expressing, and more like a project I have to maintain. I found myself many times spending hours fixing the framework I use rather than actually using it to store my ideas. I tried to get inspired from many sources and steal their systems; books, YouTube videos… I just needed a system that works so I can stop worrying about the structure of the ideas and start worrying about the ideas themselves.

The Desire Path

So what did I end up doing? Instead of choosing a system and adapting to it, why not make a system that would adapt to me?

This is a concept called the desire path — here is a 3-minute video explaining it. In a nutshell, human nature will ignore the designed paths and choose paths which are deemed more efficient. Think of those dirt trails cutting across a perfectly manicured park lawn. That’s what I wanted: stop designing paths I’ll never walk, and pave the ones I already do.

How My Brain Works

I ended up finding out that my brain works in chunks. I’d have many ideas and revelations throughout the day, some big, some not really worth the discussion. Usually I’d share them with someone next to me, or text them to a friend over WhatsApp. That’s the first chunk: raw ideas.

The ideas that are worthy, the ones I actually take action on, become things I make. Say an idea for a video game project, or an app that would make someone’s life easier. That’s the second chunk: things I build.

Then the idea opens up a whole field of research about a new topic, which is nice because we are curious about everything. The best and hardest part about these ideas is the implementation; if I thought about an idea for an app, and I actually push through and flesh out the plan, I have to learn the tools necessary to make it. And since that’s already what I do (thanks to engineering school), this is the perfect opportunity to learn new concepts and paradigms before using them in the real world. That’s the third chunk: things I learn.

So the pattern looks something like this:

A raw thought enters my head → I jot it down
Some of those thoughts turn into projects → I start building
Building forces me to learn new things → I document the knowledge This system wasn’t something I sat down and designed. It’s a pattern I noticed.

Enter Yu-Gi-Oh

And this reminded me a lot of the academy system in Yu-Gi-Oh GX (big fan, by the way).

For the unfamiliar: Yu-Gi-Oh is an anime I used to watch as a kid and have a lot of memories with. People have decks of cards they use to battle, and each card represents a monster, a spell, or a trap. Slifer, Ra, and Obelisk were the three most powerful monsters in the original series — the Egyptian God Cards. Later on, in the GX series, these gods were used as an academic division system to organize students into three dorms:

Slifer Red — the newcomers, the freshmen, the underdogs
Ra Yellow — the middle ground, more developed and serious
Obelisk Blue — the top tier, the elite

This mapped perfectly onto my three chunks:

Slifer Red → raw ideas, thoughts, blog posts. Fresh, unpolished, straight from the source.
Ra Yellow → demos, projects, practical things. Ideas that graduated into something tangible.
Obelisk Blue → study notes, resources, knowledge. The refined stuff that came from doing the work.

Beyond the Three Monsters

This doesn’t have to stop at three sections. The Yu-Gi-Oh universe has thousands of cards, and each one carries its own identity. Whenever I have a nameless project, I just throw a random monster name on top to refer to it. Need a new section someday? Pick a card. The naming system scales endlessly, and it never feels forced because the source material is that deep.

Not to mention all the gimmicks that can be reused as the system grows. Trap cards, spell cards, fusion monsters. There’s a metaphor for everything if you want one.

Ship It

That being said, this system is not done, and it is certainly not perfect. But it worked for me, and I decided to stop gatekeeping it. Maybe someone can improve upon it and share it back with us.

About

Mon, 01 Jan 0001 00:00:00 +0000

Hello, I am mehdi, you may also know me as Fluka.

I’m a firm believer that the best way to understand how something works is to break it, and try to put it back together again.

I enjoy learning about new topics, building things, and connecting ideas across different fields.

Besides Network engineering, I am interested in Design, Game Development and Tech in general

I build networks. I used to design interfaces. Now I design infrastructure: same eye, different medium. This site is where I write about what I learn and share what I find useful.

What I am working on

ataysec: just like the name suggests, this is a podcast where we get to explore security concepts in discussions with expert guests.
Missile Mayhem : a video game project that thought me how to make games, this was the first game I ever “completed” and published

Contact

Mon, 01 Jan 0001 00:00:00 +0000

I am curious to learn about things, no matter what they are, that’s why I am always open to speak in events and meet new people.

If you want to work with me, or if you have an idea and think I can help, feel free to reach out.

Email - GitHub - LinkedIn