CNAME Records: How DNS Aliases Work (and Their Limits)

A CNAME record maps one hostname (the alias) to another hostname (the canonical name). Crucially, the value of a CNAME is always a name — not an IP address. Where an A or AAAA record says "this name lives at this address," a CNAME says "this name is an alias for this other name; go look that one up instead."

The point of an alias is to keep things in sync. If many names should always resolve to wherever some central name lives, you can CNAME them all at that target and update the target's address in one place — every alias follows automatically, with no scattered IPs to edit.

Suppose you want www.example.com to always go wherever example.com goes, and you want shop.example.com to be served by an external store host. You publish two CNAMEs:

Name (host)	Type	Target
example.com	A	198.51.100.10
www.example.com	CNAME	example.com
shop.example.com	CNAME	target.hosting-provider.net

Now www.example.com resolves to whatever address example.com has — change the apex's A record and www follows with no extra edit. And shop.example.com defers entirely to the provider: when they move their infrastructure to a new address, your record never has to change.

When a resolver looks up an aliased name, it does not stop at the CNAME — it keeps going until it reaches an address. For shop.example.com above, the steps are roughly:

1. Look up shop.example.com. The answer is a CNAME pointing to target.hosting-provider.net.
2. Look up target.hosting-provider.net. The answer is its A (and/or AAAA) record — say 198.51.100.42.
3. Connect to that address.

The resolver chases the alias to its canonical name, then resolves that name's A/AAAA records to get the actual IP. A well-behaved DNS server often returns the whole chain in one response so the client does not have to make every hop itself, but the logic is the same: an alias is only useful because something with a real address sits at the end of it.

Per RFC 1034 (clarified by RFC 2181), a name that owns a CNAME record cannot own any other record type. If www.example.com has a CNAME, it must not also have an A, AAAA, MX, or TXT record. The reasoning is that a CNAME says "I am entirely an alias for another name" — so any data you want on the alias has to come from the canonical name instead.

This is the single most common CNAME mistake. You add a CNAME to point a name at a CDN, then later try to add a TXT record for domain verification on that same name — and it either fails or silently breaks the alias. The fix is usually to move the alias down to a different subdomain, or to use an apex-style workaround (below). The one technical exception is DNSSEC signing records (RRSIG, NSEC), which the zone needs to sign the data; for practical purposes, treat a CNAME name as allowing no other records. See DNSSEC for that detail.

The apex (or root) of your domain is the bare name, example.com, with no host in front. You cannot place a CNAME there — because the apex must carry SOA and NS records to define the zone and its nameservers, and the rule above forbids a CNAME from coexisting with those. A CNAME at the apex would be invalid DNS.

This is awkward when you want your bare domain to point at a provider that only gives you a hostname (a CDN, a platform host, a load balancer name). The common workarounds are provider features called ALIAS or ANAME records, or CNAME flattening: the DNS provider resolves the target hostname for you behind the scenes and answers queries for the apex with real A/AAAA records, while letting you configure it as if it were a CNAME. The record published to the world at the apex is still an address record — the flattening just happens on the provider's side.

CNAMEs show up in a few recurring patterns:

• www tracking the apex. Pointing www.example.com at example.com so the two never drift apart.
• Subdomains served by SaaS or a CDN. A provider gives you a hostname like target.hosting-provider.net and asks you to CNAME shop.example.com (or app, help, cdn) at it, so they control the underlying addresses.
• Domain-verification targets. Many services ask you to create a CNAME from a one-off subdomain (for example _some-token.example.com) to a value they specify, proving you control the domain. Note that verification often uses TXT records instead — and a TXT and a CNAME cannot live on the same name (see above).

Both ultimately get a visitor to a server; they differ in what you are committing to:

• Use an A/AAAA record when you know the literal IP address and want to point directly at it — required at the apex, and the simplest choice when the address is stable and yours.
• Use a CNAME on a subdomain when you want to delegate to another name and let that name's owner manage the underlying address — ideal for provider-hosted services, since they can change IPs without you touching anything.

The trade-off: a CNAME adds an extra lookup hop and cannot carry other records, while an A record is one hop but pins you to a specific address you have to maintain. On a subdomain that points at someone else's infrastructure, a CNAME is usually right; at the apex, or when you own the address, an A/AAAA record is.

Nothing stops a CNAME from pointing at another name that is itself a CNAME, forming a chain: a.example.com → b.example.com → target.hosting-provider.net → an address. Resolvers will follow it, but every extra link is a potential extra lookup before the client gets an IP, which adds latency to the very first connection — and a single broken or slow link anywhere in the chain delays everything below it.

Keep chains short. One alias hop to a canonical name with real A/AAAA records is the healthy shape; stacking several CNAMEs on top of each other is a common, avoidable source of sluggish first loads and hard-to-debug resolution failures.

This one bites email setups. An MX record's target must point at a real hostname with A/AAAA records — never at a CNAME. The mail standards (RFC 2181 and RFC 5321) require it, and many mail servers will refuse or mishandle a domain whose MX points at an alias. So example.com. MX 10 mail.example.com is fine only if mail.example.com is itself an A/AAAA record, not a CNAME to somewhere else.

The same rule applies to NS records: a nameserver named in an NS record must resolve via A/AAAA, not through a CNAME. The general principle is that records which name a server other systems must reliably reach — mail exchangers and nameservers — have to point at addressable hostnames, so they cannot use aliases.

To see whether a name is an alias and where it points, run a DNS lookup on who.is and read the CNAME row — it shows the canonical name the alias resolves to, alongside the rest of the record set so you can confirm there are no conflicting records on that name.

If you want the registration details behind the domain itself, a WHOIS lookup covers ownership and nameservers, which is useful when an alias points at a third-party host you want to identify.