Can I put a CNAME on my root domain to point it at a server?

Not on the bare root (example.com with nothing in front). RFC 1034 §3.6.2 says a CNAME can't coexist with any other record at the same name, and the root of every zone is required to carry SOA and NS records. A CNAME there would collide with them, so a correct nameserver refuses it. Point the root at an IP with an A record instead. If your host only gave you a hostname and not an IP, use your DNS provider's flattening feature — Cloudflare calls it CNAME flattening, Route 53 calls it an ALIAS record, others call it ANAME — which resolves the target to an A record for you at serve time. Subdomains (www, blog, shop) have no such restriction and can use a CNAME freely.

What's the difference between an A record and an AAAA record?

An A record maps a name to an IPv4 address (like 203.0.113.10); an AAAA record maps the same name to an IPv6 address (like 2001:db8::10). They're independent — a name can have one, the other, or both. If your server has both a v4 and a v6 address and you publish only an A record, IPv6-only clients can't reach it; if you publish an AAAA pointing at an address the server isn't actually listening on, IPv6 users get timeouts while everyone on IPv4 sees a working site. Publish AAAA only once the server genuinely answers on that v6 address.

I added the A record but the site still doesn't load — did I do it wrong?

Usually not. Two things stall a correct record. First, propagation: your own resolver may still be holding the old answer (or the old NXDOMAIN) until the record's TTL expires, so a fresh record can take minutes to hours to show up everywhere. Second, the host field: many control panels append the zone to whatever you type, so entering 'example.com' in the name box can silently become example.com.example.com. Use @ (or a blank field) for the root and the bare label for a subdomain. Check the record from several resolvers before assuming the value is wrong.

A Record: Point Your Domain to a Server IP

Problem

You bought a domain and you rented a server, and somewhere there’s an IP address — 203.0.113.10 — that the server answers on. Now you need the domain to point at that IP. The hosting docs say “just add an A record,” you add one, and either nothing happens or the site resolves to the wrong place. Sometimes the control panel won’t even let you save it.

The A record is the most basic thing in DNS — a name, an IP, done — and it’s still the step people get stuck on, because two details nobody mentions decide whether it works: where in the domain you’re putting the record, and what the host field actually does with the text you type. Get those two right and this is a two-minute job.

What an A record actually is

An A record is one line in your domain’s DNS zone that maps a name to an IPv4 address. That’s the whole job:

shop.example.com.    A    203.0.113.10

A resolver asks “what’s the address for shop.example.com?”, gets 203.0.113.10, and connects there. Its sibling, the AAAA record, does the identical thing for IPv6 addresses. A name can carry an A record, an AAAA record, or both — they’re separate answers to separate questions, and a browser will try whichever the network gives it.

There’s no magic and no “linking.” You are publishing a fact — this name lives at this address — and every resolver on the internet reads that fact and routes accordingly. Which is exactly why the two failure modes below are so common: they’re not bugs in DNS, they’re you publishing a slightly different fact than the one you meant.

The apex trap: you can’t CNAME the root

Here’s the rule that breaks more domain connections than any other. Your root domain — example.com with nothing in front of it, also called the apex or zone apex — cannot hold a CNAME.

The reason is structural, not a vendor quirk. RFC 1034 §3.6.2 says that if a CNAME exists at a name, no other record type may exist there. But the apex of every zone is required to carry an SOA record and its NS records — that’s what makes it a zone at all. A CNAME at the apex would have to coexist with those, which the spec forbids, so a correct nameserver simply refuses it.

This matters because a lot of hosts — especially platforms like Vercel, Netlify, or GitHub Pages — hand you a hostname to point at, not an IP. On a subdomain that’s fine; you make www.example.com a CNAME to their hostname and move on. But you cannot do the same on the bare example.com. Your options at the apex are:

An A record to their IP, if they publish a stable one (many don’t, because they move addresses).
Your DNS provider’s flattening feature: Cloudflare’s CNAME flattening, Route 53’s ALIAS, others’ ANAME. You enter the target hostname, and the provider quietly resolves it to A records and serves those at the apex — giving you CNAME-like behavior without an actual apex CNAME.

If your registrar’s DNS doesn’t offer flattening and your host only gives you a hostname, the standard move is to point www at the hostname with a CNAME and redirect the bare domain to www.

The host-field trap: your name got doubled

The second silent killer lives in the “Name” or “Host” box of your DNS panel. Almost every panel appends your domain automatically to whatever you type there. So if you want a record for example.com and you type example.com in that box, you may have just created a record for example.com.example.com — which resolves for nobody.

The conventions, once you know them, are consistent:

For the root domain, type @ (or leave the field blank — panels differ). Not example.com.
For a subdomain, type only the label: shop, not shop.example.com.

If you added a record, saved it without error, and the name still won’t resolve, look at the host field before you touch anything else. A doubled name is the single most common “I added it and it didn’t work.”

How to check your A record

The order is quick and it isolates the problem every time:

Look up the record and read the value. Query the A record for the exact name you set. If you get an answer but it’s the wrong IP, or you get an answer for a doubled name, that’s a data problem — fix the record.
Confirm the name is what you think. Watch for the doubled-domain trap. dig example.com A and dig example.com.example.com A will tell you instantly which one you actually created.
Check more than one resolver. A change that’s live on one resolver and stale on another is propagation, not a mistake. Give it up to the record’s TTL before deciding the value is wrong.
Confirm the server answers there. A correct A record pointing at an IP where nothing is listening gives you a resolving name and a dead connection — a different problem entirely (the DNS did its job).

Check it with DechoNet

DNS Lookup reads the live A and AAAA records for any name, so you can confirm the value, catch a doubled host name, and see whether the apex is answering with an address at all.
DNS Propagation checks the record across resolvers in different networks at once, which is how you tell “I made a mistake” apart from “it just hasn’t spread yet.”

Resolution Checklist

Decide where the record goes: root (@) or a subdomain (bare label like shop). Never type the full domain into the host field.
At the root, use an A record to an IP — or your provider’s ALIAS/ANAME/CNAME-flattening if the host only gave you a hostname. Never a raw CNAME at the apex.
On a subdomain, an A record (to an IP) or a CNAME (to a hostname) are both fine — pick based on what the host gave you.
Publish AAAA only if the server actually answers on that IPv6 address; otherwise leave it off.
After saving, verify the exact name resolves to the exact IP across several resolvers, and wait out the TTL before assuming it’s broken.

When to Escalate

If the record is correct and resolving but the site still won’t load, the problem has moved past DNS — the server isn’t listening on that port, a firewall is dropping the connection, or TLS is misconfigured. That’s a connectivity or certificate issue, not a record.
If you need apex behavior toward a hostname that changes IPs and your DNS provider offers no flattening, you likely need to move your DNS to one that does — hand-copying the target’s current IPs into an A record will break the moment the host renumbers.
If different resolvers disagree for far longer than your TTL, check that the domain’s nameservers at the registrar actually match the DNS provider holding your records — a nameserver mismatch means half the internet is reading a different zone than you’re editing.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.