on this page
- What a domain actually is
- DNS is a phone book, and the analogy holds up
- Nameservers: who’s allowed to answer
- The records, in plain language
- Apex vs www, and why www is the weird one
- Common DNS record types
- TTL and propagation: why nothing is instant
- Classic traps
- Getting your real project onto its real name
Your app is deployed. It works. It lives at your-app.pages.dev and you’ve shown three friends, who all said “nice” and then asked, very reasonably, “what’s the actual address?” Because your-app.pages.dev is a fine place to test, but it’s nobody’s idea of a name you put on a business card. You want raindev.fyi. You bought raindev.fyi. And somewhere between owning the name and the name actually working, there is a settings panel full of dropdowns that say things like A, CNAME, and TTL, and it is not at all obvious which one you’re supposed to touch.
If the overview guide gave you the one-paragraph version of DNS, this is the part where we slow down and actually look at the machine. None of it is hard once you can see the shape of it. It’s just unfamiliar, and unfamiliar plus a live website feels scary. Let’s fix the unfamiliar part.
What a domain actually is
A domain is the human-friendly name people type instead of a string of numbers. Computers route traffic by IP address (Internet Protocol address), something like 104.21.5.20, and nobody wants to hand that out at a meetup. So we put a readable name in front of it: raindev.fyi.
Here’s the part people get wrong: you don’t buy a domain, you rent it. There’s a yearly fee, and if you stop paying, it goes back on the market and someone else can grab it. You pay that fee to a registrar, a company licensed to lease out names. The usual suspects are
That last word, point, is the whole game. Owning the name and making the name load your site are two completely separate steps, and the gap between them is where everyone gets stuck.
DNS is a phone book, and the analogy holds up
DNS (Domain Name System) is the internet’s phone book. You know a person’s name; the phone book turns it into a number you can actually dial. You know raindev.fyi; DNS turns it into the IP address your browser actually connects to.
The analogy is worth stretching a little, because it explains things that otherwise feel like magic. A phone book is published by some specific company. There can be more than one phone book floating around, and they don’t update at the same moment. If you change your number, the new book doesn’t reach everyone’s doorstep instantly; the old book is still sitting on a lot of shelves saying the old thing. Hold onto that, because it’s exactly why DNS changes are never instant.
Nameservers: who’s allowed to answer
When someone’s browser asks “what’s the IP for raindev.fyi?”, the question has to land somewhere. The servers that hold the official answer are your nameservers. They’re the published phone book for your domain, the one source the rest of the internet trusts.
Here’s the move that trips up every beginner. Your registrar sells you the name, and by default they also run the nameservers, so their DNS panel is the one that’s live. But you can change the nameservers to point at a different company. The three realistic options:
- Your registrar’s DNS. You bought the name at Namecheap, you manage records at Namecheap. Simplest mental model, fewest moving parts.
- Your host’s DNS. Some hosts let you move the nameservers to them so they can manage records automatically. Vercel and Cloudflare Pages both support this.
- Cloudflare’s DNS (used as a standalone layer in front of any host). It’s free and fast, and it hands you caching and a pile of other tools on top. Very common, even when the domain was bought somewhere else.
All three are fine. The catastrophe is mixing them up.
The records, in plain language
Once you know where to edit, you edit DNS records: individual lines that each say “this name maps to this thing.” A handful of types cover almost everything you’ll do.
An A record maps a name to an IPv4 address (the classic 104.21.5.20 style). It’s the most direct “this name lives at this number” line there is. An AAAA record does the same job for an IPv6 address, the newer, much longer address format that looks like 2606:4700::6810:514. Same idea, different number scheme.
A CNAME record (Canonical Name) is the interesting one: instead of pointing a name at a number, it points a name at another name. This is how static hosts want you to connect. Your host gives you a target like your-app.pages.dev, and you tell DNS that www.raindev.fyi is an alias for it:
Type Name Value
CNAME www your-app.pages.dev
The beauty of a CNAME is that you never have to know or care about the host’s actual IP address. If Cloudflare reshuffles their servers, your-app.pages.dev quietly updates and your CNAME keeps working. You pointed at a name, not a number, so you’re insulated from the number changing.
A TXT record holds plain text. It doesn’t route traffic at all; it’s just a place to park a string for something else to read. Two big uses: proving you own a domain (a host says “add this exact code as a TXT record,” then checks that it’s there) and email authentication, where records named SPF and DKIM tell the world which servers are allowed to send mail as you.
Apex vs www, and why www is the weird one
Your apex (also called the root or bare domain) is raindev.fyi with nothing in front of it. The www version is www.raindev.fyi, which is technically a subdomain. People treat them as the same site, and they should resolve to the same site, but to DNS they are two different names that each need their own record.
Now the gotcha that has eaten entire afternoons: you cannot put a plain CNAME on the apex. It’s a rule baked into how DNS works. The apex has to carry other records too (your MX mail records, for one), and a CNAME legally takes over the entire name, leaving no room for anything else. So a raw CNAME at the root is simply not allowed.
Hosts solve this with workarounds that all do the same thing behind a friendlier name. You’ll see ALIAS, ANAME, or CNAME flattening: pick one in your panel, point it at your-app.pages.dev, and the DNS provider quietly looks up the IP for you and serves it like an A record, while letting you write a name. If your host gives you a flat IP instead, you just use a plain A record at the apex and skip the cleverness.
The standard, boring, correct setup is to configure both names and have one redirect to the other. Most people send the apex to www, or www to the apex; the choice barely matters, as long as you don’t leave one of them dead.
Common DNS record types
Here’s the cheat sheet. You’ll use the first three constantly and meet the rest as needed.
| Record | Maps a name to | Typical use |
|---|---|---|
| A | An IPv4 address | Point the apex at a host that gives you an IP |
| AAAA | An IPv6 address | Same as A, for the newer address format |
| CNAME | Another name | Point www at your-app.pages.dev |
| TXT | A line of text | Domain verification, plus SPF and DKIM for email |
| MX | A mail server (by name) | Tell the world where to deliver your email |
| NS | A nameserver | Declares which DNS servers are in charge of the zone |
TTL and propagation: why nothing is instant
Two terms explain every “I changed it, why isn’t it working?” moment.
TTL (Time To Live) is a number attached to each record that says how long a resolver is allowed to cache, meaning remember, the answer before asking again. A TTL of 3600 means “hang onto this for 3600 seconds (one hour) before you bother re-checking.” Caching is what keeps DNS fast: your browser doesn’t run a fresh lookup on every single click. But it’s also the reason a change isn’t immediate. Resolvers all over the world are still holding the old answer until their copy expires.
Propagation is the wait while all those stale copies age out and the new record spreads. There’s no single switch that flips everywhere at once. Instead, thousands of caches each expire on their own clock. In practice, changes usually take effect in minutes, but the honest upper bound is up to 48 hours for the slowest, most stubborn resolvers to let go.
Classic traps
Almost every broken-domain story is one of these five.
| Trap | What it looks like | The fix |
|---|---|---|
| Pointing at the wrong target | Site loads someone else’s page, or a host error | Copy the host’s exact target; no typos, no guessing |
| Mixing registrar and host DNS | Records look perfect, change does nothing | Edit only at whoever holds the nameservers |
| Forgetting www or the apex | One address works, the other dead-ends | Set up both names, redirect one to the other |
| CNAME on the apex | Panel rejects it, or behaves strangely | Use ALIAS, ANAME, CNAME flattening, or an A record |
| Expecting instant changes | ”It’s been two minutes and it’s broken” | Wait it out; lower TTL ahead of planned changes |
If your domain isn’t loading, walk that table top to bottom before you blame your host. It’s nearly always one of these, and it’s nearly always the second row.
Getting your real project onto its real name
That’s the entire machine. A registrar rents you a name, nameservers decide which company answers for it, records inside that company’s DNS map the name to your host, and TTL plus propagation explain why you sometimes have to go make coffee while it settles.
So go finish it. The app you’ve been calling your-app.pages.dev was always meant to live somewhere a person would actually type. Point the apex, point the www, set the redirect, give it twenty minutes, and load raindev.fyi in a fresh tab. The next time someone asks for the address, you get to say the real one.