Skip to content

CNAME record

www.example.com and example.com are almost always the same site, served by the same infrastructure. Keeping two separate A records in sync every time that infrastructure's address changes is exactly the kind of duplicated bookkeeping DNS was designed to avoid — and the record that avoids it is the CNAME, short for Canonical Name.

An alias, not an address

A CNAME record doesn't store an IP address at all. It stores another domain name — the "real," canonical name that a resolver should look up instead:

www.example.com.    IN  CNAME   example.com.

Query www.example.com, and a resolver following this record doesn't stop there. It sees the CNAME, takes the name it points to, and looks that name up as if it had been asked in the first place:

dig www.example.com A

;; ANSWER SECTION:
www.example.com.     3600    IN  CNAME   example.com.
example.com.         3600    IN  A       93.184.216.34

Both records show up in a single answer, because resolving www.example.com's address genuinely requires both steps: follow the alias, then resolve the name it points to. Change example.com's A record later, and www.example.com updates automatically along with it — there's exactly one address to maintain, not two kept manually in sync.

Two hard restrictions worth knowing before they surprise you

RFC 1035, later sharpened by RFC 2181, places two restrictions on CNAME that aren't optional style preferences — they're structural rules a resolver actually enforces.

A name with a CNAME record can have no other record type. If www.example.com has a CNAME, it cannot also have an A record, an MX record, or anything else at that exact name — RFC 2181 states plainly that a name is either a CNAME alias or it holds ordinary records, never both. This is precisely why a zone apex — the bare domain itself, example.com with no subdomain — almost never carries a CNAME: the apex is required to hold SOA and NS records, and a CNAME there would conflict with records that have to exist regardless.

An MX or NS record should never point at a CNAME as its target. MX records name a mail server, and that name is expected to resolve directly via its own A or AAAA record — not via another layer of alias indirection. RFC 2181 flags exactly this as undesirable, and in practice, some mail servers simply refuse to follow it, silently failing delivery rather than resolving the extra hop.

Practical scenario: a CDN migration that breaks the homepage

A team moves their site behind a CDN and follows the provider's instructions: create a CNAME from their domain to the CDN's hostname. It works instantly for www.example.com — but the same change applied to the bare example.com fails to save at all, with the DNS provider's control panel rejecting it outright.

Attempted:
example.com.    IN  CNAME   cdn.example-provider.net.

Rejected — reason:
example.com. already has SOA and NS records at this name

This isn't a provider bug or an arbitrary restriction — it's the first rule above showing up directly. The zone apex is required to carry SOA and NS records for the zone to function as a zone at all, and a CNAME can't share a name with any other record type. Because www isn't the apex, and by convention doesn't need to hold SOA or NS records itself, the CNAME there was never in conflict with anything.

The actual fix depends on what the CDN provider supports: many now offer a proprietary workaround — commonly called "CNAME flattening" or an "ALIAS" record — that behaves like a CNAME to the operator configuring it, but is resolved server-side into a plain A record before it's ever handed to a client, sidestepping the apex restriction entirely without violating it. It's provider-specific, not a standard DNS record type in its own right, which is worth confirming directly in that provider's documentation before assuming it behaves identically to a real CNAME.

Common mistakes

  • Trying to CNAME a zone apex. The SOA/NS conflict above isn't a workaround waiting to be found — some form of provider-specific flattening or ALIAS record is the only real answer.
  • Pointing an MX or NS record's target at a CNAME instead of a hostname with its own A record. Standards discourage it, and plenty of real mail software enforces that discouragement by simply failing rather than resolving the extra alias hop.
  • Chaining CNAMEs several layers deep. a → b → c → d technically works, but every added link is another full lookup a resolver must perform before it has a usable address, and every unnecessary hop is latency a single, direct CNAME wouldn't have cost.

Practice exercises

  1. Run dig www.<a-large-site> A against a domain you suspect uses a CDN and look for a CNAME step in the answer section before the final A record.
  2. Explain, using RFC 2181's rule, exactly why a name can't hold both a CNAME and an MX record simultaneously.
  3. A teammate proposes CNAME-ing the bare domain apex directly to a hosting provider's hostname. Explain what specifically prevents this in standard DNS, and name one real-world workaround providers offer instead.

CNAME and MX both carry a domain name as their payload rather than an address — but neither one is meant to carry arbitrary free-form information. That's a different record type's entire purpose, one deliberately designed to hold nothing but text: TXT record.

Sources