I was vibe coding my first website until the DNS screen humbled me. Here is how that stuff actually works.

If you’ve been building stuff recently in this whole "vibe coding" wave, you probably know the exact feeling I'm talking about. You sit down with your AI tool, prompt your way through building a clean little web app in an afternoon, and everything feels effortless. The code writes itself, the previews work, and you finally buy that domain name you’ve had floating in your head for three weeks.

Then comes the moment you try to connect that shiny domain to your live project on Vercel or whatever host you’re using.

Suddenly, the AI stops talking like a conversational collaborator and starts throwing strings of technical jargon at you: "Go to Cloudflare, add an A record with @ pointing to 76.76.21.21, then create a CNAME for www pointing to cname.vercel-dns.com."

We paste it in, we wait five minutes, and miraculously it works. Ninety-nine percent of the time, nobody questions it. But if you’re like me, doing something without understanding what is happening behind the curtain feels deeply unsatisfying. Why an A record here? Why a CNAME there? What even is the @ symbol, and why does the whole internet need several minutes to agree that my site exists?

I went down the rabbit hole to unpack the mechanics, and it turns out the mental model is a lot more intuitive than those configuration dashboards make it look.

Think back to the very first step of building your site locally. Before putting anything on the public web, your AI probably told you to test your project at something like localhost:3000 or 127.0.0.1:3000. That string of four numbers isn't arbitrary. It’s an IP address, specifically the universal address that tells your computer to talk directly to itself.

That reveals the fundamental truth of how the web operates: the internet does not speak in human words. Routers, network switches, and browser engines couldn't care less about fancy Latin-character brand names. They exclusively route traffic using numbers. Back in the early days of the net, we built the IPv4 standard—roughly 4.3 billion unique addresses made up of those familiar four-block numbers like 76.76.21.21. We’ve since run through the unassigned supply of those IPv4 blocks (which is why you keep hearing engineers talk about the transition to the virtually limitless IPv6 format), but the foundational rule remains unchanged: every single machine connected to the internet needs a numerical coordinates system.

So when you buy a domain name, you aren't really buying a piece of software. You're buying a human-friendly nickname, a phonebook entry that exists to shield people from having to memorize a random string of numbers.

The mechanism that binds that nickname to your actual server breaks down into three core fields on your DNS screen: the record Type, the Name, and the Target.

When you configure an A Record, you are setting up the most direct bridge possible. The "A" literally stands for Address. You are telling every browser on earth: "When someone asks for this name, send them straight to this exact IPv4 number." If you know the exact static IP of the server running your code, you use an A record (or an AAAA record if you’re pointing directly to an IPv6 address).

That explains the IP part, but why would we ever use a CNAME instead?

Imagine a hosting company like Vercel. They aren't running your site on a lonely beige computer tower sitting under someone's desk with a fixed IP address. They manage massive, elastic cloud infrastructure across the world. They might rotate their backend servers, rebalance network traffic, or shift edge locations tomorrow. If millions of users had hardcoded Vercel’s raw IP addresses into their personal domain dashboards, Vercel could never adjust their internal routing without breaking half the internet.

This is where the CNAME (Canonical Name) comes in. Instead of mapping your domain to an IP address, a CNAME aliases your domain to another domain name. When you point [www.yourproject.com](https://www.yourproject.com) to cname.vercel-dns.com, you are basically saying: "Hey, I don't know which physical server Vercel is spinning up today. Just go ask cname.vercel-dns.com where it's currently living, and forward my visitors there." It creates an abstraction layer that keeps your setup from breaking when the host updates its infrastructure.

Then you hit the Name field (sometimes labeled as "Host" or "Subdomain"), which trips a lot of people up.

Most of the time, you don't just want one single destination. You might want yourproject.com to hit your landing page, but next month you might build a backend tool that you want to host at api.yourproject.com, or a customer documentation site hosted on an entirely different platform at docs.yourproject.com. The Name field is how you split that single brand into different departments.

If you type www or api into that box, you are creating a subdomain that routes visitors to a specific target. But what happens when you want to route the main, naked domain itself—the apex address without any www or prefixes attached? DNS dashboards couldn't just leave that field blank without causing parsing ambiguities, so the industry standardized on using the @ symbol as shorthand to represent the root domain zone itself. When you see @ in an A record pointing to an IP, it simply means: "This rule applies to the plain domain name, unmodified."

Finally, there is the mystery of the waiting game. Why do we hit save, only to be told that we need to wait anywhere from two minutes to twenty-four hours for the change to go live?

A lot of people assume there is one giant, central computer hub in an ICANN basement somewhere that manages every website on earth, and we're just waiting for that machine to receive our update. But if the internet relied on a single centralized database, a power outage in one facility would bring the entire global economy to a halt.

Instead, DNS is distributed across a massive, redundant hierarchy. At the absolute top sit the 13 Root Server entities—which are replicated into thousands of physical locations around the globe via Anycast routing so they can never be knocked offline at once. Beneath them sit the registries for specific extensions (like the systems that handle all .com or .org domains), and beneath those sit your Authoritative Nameservers at providers like Cloudflare.

When you save a new record, your provider updates their authoritative servers almost instantly. But your local Internet Service Provider, your home Wi-Fi router, and your browser all aggressively cache previous lookups so they don't have to query the global network every single time a page refreshes. The wait time isn't the internet being slow; it’s simply the time it takes for local caches across the world to expire their old memory and pull down your fresh configuration.

Once you see how the layers stack up, the DNS dashboard stops feeling like a black box of random strings to copy-paste. It’s just a distributed directory where you’re deciding whether to hand the world a direct address, set up an alias, or split your traffic across different doorways under the same roof.