Every host hands you DNS instructions in its own dialect: “Add an A record to 76.76.21.21” or “Point your CNAME to cname.vercel-dns.com.” If those sentences feel arbitrary, you have not yet seen the one-page model of DNS. This page is that model, with the exact values the big three indie hosts (Vercel, Firebase, Netlify) ask for as of June 2026.
TL;DR
An A record maps a name to an IPv4 address. A CNAME maps a name to another name. Use an A record (or ALIAS) for the root domain yoursite.com; use a CNAME for subdomains like www.yoursite.com. When your host tells you which to use, follow its instruction over any rule of thumb. Two gotchas cause most failures: you cannot put a plain CNAME on the root domain, and you cannot have an A record and a CNAME on the same name.
What a record actually is
DNS translates names (yoursite.com) into addresses (93.184.216.34) so the browser knows where to connect. A record is one entry in your domain’s zone that performs part of that translation. As an indie dev you will touch two of them roughly 99% of the time:
- A — points a name at an IPv4 address, e.g.
yoursite.com → 76.76.21.21. - CNAME — points a name at another name, e.g.
www.yoursite.com → cname.vercel-dns.com, and the resolver chases that name to its IP.
The rest (AAAA for IPv6, MX for mail, TXT for verification, NS for nameservers, CAA for certificate authorities) come up occasionally, and one of them — TXT — shows up in nearly every host setup as an ownership-proof record.
When you are hitting this problem
You are reading the right page if any of these match:
- You added a domain in Vercel / Firebase / Netlify and it shows “Invalid Configuration”, “verification pending”, or “Needs DNS records”.
- You opened your domain after setup and got a “This site can’t be reached” /
DNS_PROBE_FINISHED_NXDOMAINpage. www.yoursite.comworks but the bareyoursite.comdoes not (or the reverse).dig yoursite.comreturns the wrong IP, or no answer at all.
The rule, in one table
| You are pointing | Record type | Name field | Value (example) |
|---|---|---|---|
Root / apex (yoursite.com) | A (or ALIAS) | @ or blank | The IP your host gives (e.g. 76.76.21.21) |
www subdomain | CNAME | www | The hostname your host gives (e.g. cname.vercel-dns.com) |
Any other subdomain (app, blog) | CNAME | app, blog | The hostname your host gives |
| IPv6 (only if your host supports it) | AAAA | same as the A | An IPv6 address |
The reason root has to be an A record: the DNS spec (RFC 1034) forbids a CNAME coexisting with the other records every apex must carry, such as SOA and NS. Providers that “let” you CNAME the apex are quietly substituting a flattened record (see below).
Exact values for the big three hosts (June 2026)
Always copy the value from your own host dashboard — these are the published defaults, but some hosts hand you a project-specific value.
| Host | Apex (yoursite.com) | www subdomain | Extra step |
|---|---|---|---|
| Vercel | A → 76.76.21.21 (or ALIAS to the supplied *.vercel-dns.com) | CNAME → cname.vercel-dns.com (newer projects get cname.vercel-dns-NNN.com) | None; Vercel does not support AAAA/IPv6 |
| Firebase Hosting | A → the IP(s) shown in the Add custom domain wizard (e.g. 199.36.158.100) | A record to the same IP(s), not a CNAME | A TXT ownership record the wizard provides |
| Netlify | A → 75.2.60.5, or ALIAS/ANAME to apex-loadbalancer.netlify.com | CNAME → your-site.netlify.app | None |
Note the odd one out: Firebase tells you to put A records on both the apex and www (pointing at the same IPs) and to add a TXT verification record. Vercel and Netlify use the classic A-at-root / CNAME-at-www split.
Sources: Vercel DNS docs, Firebase custom domain docs, Netlify external DNS docs.
Step by step
- Decide what you are pointing: the root (
yoursite.com) or a subdomain (www,app). - Read your host’s instruction. An IP means an A record; a hostname means a CNAME.
- Log in to whoever runs your DNS — Cloudflare, your registrar’s built-in DNS, Route 53, etc. (Whoever your nameservers point to owns the records; edits anywhere else are ignored.)
- Root domain: add an A record, Name
@(or blank), Value = the IP they gave you. www: add a CNAME, Namewww, Value = the hostname they gave you (e.g.cname.vercel-dns.com).- Add any TXT verification record the host requested (Firebase always; others for some setups).
- Save. Vercel-hosted DNS applies in roughly 60 seconds; external providers vary with TTL.
- Verify with
dig yoursite.com +short(Mac/Linux) ornslookup yoursite.com(any OS); the answer should match what you set. - Return to the host dashboard. It should flip from “pending” to “active” once it sees the right record — Firebase may take a few hours for the SSL certificate, up to 24 hours.
What an A and CNAME look like in the editor
Type Name Value TTL
A @ 76.76.21.21 60
CNAME www cname.vercel-dns.com. 60
TXT @ "vercel-verify=abc123..." 60How to verify after saving:
# Check the A record on the root
dig yoursite.com +short
# Expected: 76.76.21.21
# Check the CNAME on www (returns the target name, then the resolved IP)
dig www.yoursite.com +short
# Force a non-cached lookup against Cloudflare's public resolver
dig @1.1.1.1 yoursite.com +shortIf dig returns the old value, your local resolver is still caching it — wait out the TTL or query a public resolver directly as shown above.
CNAME at the root: flattening, ALIAS, and ANAME
You will eventually want to point the apex at a hostname (because your host only gives you a CNAME target, not an IP). Standard DNS forbids it, so providers offer one of these workarounds, all of which resolve down to an A/AAAA answer at query time:
- CNAME flattening — Cloudflare’s term. It runs the lookups for you and returns the final IP. It is on by default for the apex on every Cloudflare plan; paid plans can flatten all CNAMEs.
- ALIAS — DNSimple’s name for the same idea.
- ANAME — DNS Made Easy’s name for it.
- HTTPS record (RFC 9460) — a newer apex-friendly record some hosts (including Vercel) now support; not every old client understands it yet.
If your provider offers none of these, fall back to a plain A record with the host’s published IP.
The six mistakes that cause 90% of broken setups
- CNAME on the root without flattening/ALIAS — most providers reject it outright.
- An A record and a CNAME on the same name — DNS does not allow both; remove one.
- Long TTL during a migration — drop TTL to 60–300 seconds a day before the switch so the new value propagates fast.
- DNS pointed at the host but the domain never added in the host dashboard — DNS is one-directional; the host still has to claim it.
- Stale records left behind that point to an old provider — resolvers will serve them; delete cleanly.
- Editing records at the registrar while nameservers point to Cloudflare (or the reverse) — your edits land on a server nobody queries.
FAQ
- Can I use a CNAME for the root domain?: Not a plain CNAME — RFC 1034 forbids it because the apex must also carry SOA/NS records. Cloudflare’s CNAME flattening, DNSimple’s ALIAS, DNS Made Easy’s ANAME, and the newer HTTPS record all mimic it and resolve to an IP at query time. When none are available, use an A record.
- What is the difference between ALIAS, ANAME, and CNAME flattening?: Functionally nothing — they are three vendors’ names for “CNAME-like behavior at the apex.” ALIAS is DNSimple, ANAME is DNS Made Easy, and CNAME flattening is Cloudflare. All return an A/AAAA answer to the client.
- How long should TTL be?: 60–300 seconds during a migration so changes apply quickly; 3600 seconds (1 hour) or higher once the setup is stable. Vercel-managed DNS defaults to 60 seconds. Lower TTL means faster updates and slightly more query traffic.
- Why does Firebase want A records on
wwwinstead of a CNAME?: Firebase serves both the apex andwwwfrom the same anycast IPs, so it has you put A records (and a TXT ownership record) on each rather than chainingwwwthrough a CNAME. - Do I need an AAAA record?: Only if your host gives you an IPv6 address. Vercel does not support IPv6, so you can skip AAAA there entirely. Add one only when the host explicitly provides an IPv6 value.
- My records look right but the site is still down — why?: Most often it is caching (wait out the TTL, or test with
dig @1.1.1.1), an un-claimed domain in the host dashboard, or DNS edited at the wrong place (registrar vs. nameserver host). Check those three before assuming the records are wrong.