CNAME vs A record, and why the apex is special.

Published 2026-09-16 · 5 min read · Kirk Diamond

A and AAAA: a name to an address

An A record maps a name to an IPv4 address; AAAA does the same for IPv6. They are the end of the road: a resolver that gets an A record has its answer. You can publish several for one name and clients will pick one (round robin, roughly). They are the right choice when you control the address and it will not change: your own server, a static IP from your cloud provider, a load balancer with a reserved address.

Their weakness is that they are a copy of something you may not own. Point www.example.com at 203.0.113.10 because that is what your hosting provider's load balancer resolved to today, and the day the provider moves that load balancer, your site is down while every other customer using the provider's hostname is fine. If the target is somebody else's infrastructure, you want to be pointing at their name, not their number.

CNAME: a name to another name

A CNAME says "this name is an alias for that name; go and look up that instead". The resolver follows it, possibly through several links, and returns whatever the final name has. So www.example.com CNAME example-com.cdnprovider.net means your site follows the CDN's addresses wherever they go, which is exactly what you want for anything hosted by someone else: CDNs, static site hosts, SaaS apps on a custom domain, load balancers with changing addresses.

Two rules make CNAMEs awkward. First, a name that has a CNAME may have no other records. Not MX, not TXT, not NS, nothing. The CNAME replaces the whole name, and the resolver will fetch the target's records of whatever type you asked for. Second, a CNAME chain adds a lookup per link, and each link is another place for a stale cache or a broken target. Two or three links is normal (your name, the CDN's customer name, the CDN's regional name); ten is a sign something is wrong.

Why a CNAME at the apex fails

The apex, or root, of a zone is the bare domain: example.com rather than www.example.com. The apex must carry the zone's SOA record and its NS records; that is what makes it a zone. And a name with a CNAME may have no other records. So a CNAME at the apex would conflict with the SOA and NS that have to be there, and RFC 1034 forbids it. Most DNS providers refuse to let you create one. The few that allow it produce a zone that is broken in ways that show up as intermittent SERVFAIL and mail that cannot find your MX records.

This is a real inconvenience, because the apex is exactly where you most want to alias: everyone types example.com, and the thing you want it to reach is a CDN or a hosting platform that only gives you a hostname.

ALIAS, ANAME and CNAME flattening

Providers solved this with a record type that exists only inside their own system. Called ALIAS (DNSimple, Route 53's alias, NS1), ANAME (some registrars) or CNAME flattening (Cloudflare), it works the same way: you enter a target hostname, and the authoritative server resolves it on your behalf and answers queries for your apex with plain A and AAAA records containing the target's current addresses. To the rest of the internet, and to the DNS lookup tool, your apex simply has A records. The provider re-resolves the target periodically so the addresses track changes.

Things to know about it:

• It is not a standard. Move your DNS to a provider without it and your apex record does not come with you.
• The resolution happens from the provider's servers, so any geographic steering the target does (a CDN answering with the nearest edge) is done relative to the DNS provider's location, not the visitor's. Some providers pass the client subnet through to fix this; many do not. For a CDN apex this is worth checking.
• The TTL you see on the flattened A records is the provider's choice and is usually short.

The alternative, if your provider does not offer any of these, is the old one: put the site on www with a CNAME, and have the apex serve a 301 redirect to www from a small fixed-address host or the registrar's redirect service. It is one extra hop for the people who type the bare domain, which is most of them, so aliasing is better when you can get it.

The CNAME side effects people forget

• Mail on a CNAME'd name. Because a CNAME hides every other record, adding CNAME to a name that had MX or a DKIM TXT record deletes them in effect. If a subdomain sends or receives mail, it cannot be a CNAME.
• Verification records. SaaS domain verification usually asks for a TXT record on the exact name. If that name is a CNAME, you cannot add it. Providers know this and generally offer a _something.name TXT instead.
• CNAME to a CNAME to nothing. The chain is only as good as its last link. A target that returns NXDOMAIN takes the whole chain with it. The lookup tool shows every link so you can see where it stops.
• Certificate validation. ACME HTTP and DNS challenges follow CNAMEs, which is useful: you can CNAME _acme-challenge.example.com to a zone you can update automatically. But a CAA record is looked up on the original name and its parents, not the CNAME target; see CAA records explained.

Choosing