skip to content

Why can't a DNS CNAME record be placed at the zone apex example.com, and what can you do instead?

level: middleimportance: must knowfreq 52%

answer

  1. an alias keeps its name to itself
  2. what the top of a zone must hold
  3. SOA and NS at the apex
  4. flattening is not a record type

basics

~20 s

A CNAME may not share its name with other data (RFC 2181 §10.1), yet the apex must hold the zone's SOA and NS records, so a CNAME there is illegal. Publish A/AAAA at the apex or use a provider's flattening feature.

solid answer

~50 s

RFC 1034 says that if a `CNAME` is present at a node no other data should be present, and RFC 2181 §10.1 tightens that to: an alias may carry only DNSSEC records besides its `CNAME`. The rule exists so a cached alias can be used for every query type without asking whether other data sits beside it. The zone apex always holds the zone's `SOA` record and its `NS` RRset, and usually `MX` and `TXT` too, so a `CNAME` there collides with data the zone cannot exist without. The standard answer is to publish `A` and `AAAA` records at the apex, make `www` the alias, and redirect the bare domain to `www` at the web layer if you need to. Some DNS providers offer a flattening feature, often called ALIAS or ANAME, that resolves a target and serves plain `A`/`AAAA` records, but it is a server feature, not a standard record type.

go deeper

for a junior

Remember the short version: a CNAME must be alone at its name, and the top of a zone always holds other records, so the bare domain cannot be a CNAME.

for a middle

Explain RFC 1034's two reasons, consistency and cached aliases, name the SOA and NS records every apex holds, and list the standard alternatives.

for a senior

Weigh apex addresses against provider flattening for a hosted platform: who tracks address changes, what the flattened answer reflects, and what you lose when moving providers.

for a principal

Treat apex handling as a vendor-coupling decision: a flattening feature ties the zone to one provider's behaviour, which matters for multi-provider DNS and exit plans.

## The rule A **CNAME** ("canonical name") record makes its owner name an **alias** of another name, the canonical name. RFC 1034 §3.6.2 states the constraint: if a CNAME record is present at a node, **no other data should be present**. RFC 2181 §10.1 makes it exact. For any name, exactly one of these holds: - one CNAME record exists, optionally with DNSSEC records (RFC 2181 named the original SIG, NXT and KEY types; DNSSEC's current record types replaced them); - one or more records exist, none of them a CNAME; - the name exists but has no records; - the name does not exist at all. There may also be only **one** CNAME per alias: an alias has a single canonical name. ## Why the rule exists RFC 1034 gives two reasons. The first is **consistency**: the data for an alias and for its canonical name cannot differ, because the alias has none of its own. The second is **caching**: a resolver holding a cached CNAME can use it for any query type without first asking an authoritative server whether other types exist at that name. A server that finds the CNAME includes it and restarts the query at the target; only a query for type `CNAME` itself is not restarted. If other data were allowed beside a CNAME, one resolver could answer an `MX` query from the alias and another from the local record, and the two would disagree. ## Why the apex specifically The **apex** is the top node of a zone, the name that owns the zone's `SOA` record and its authoritative `NS` RRset (RFC 9499). RFC 1034 describes both as the records that define the top node of every zone. So the apex is never empty: it holds data by definition, and a CNAME there always collides with it. In practice the apex also carries `MX` records for mail and `TXT` records for verification, which would collide as well. What the apex's own records contain: | Record | RDATA fields (RFC 1035) | What it carries | |---|---|---| | `SOA` | `MNAME`, `RNAME`, `SERIAL`, `REFRESH`, `RETRY`, `EXPIRE`, `MINIMUM` | primary server name, responsible mailbox, 32-bit zone version, secondary refresh timers (seconds), and the field RFC 2308 uses to bound negative-caching TTL | | `NS` | `NSDNAME` | the host name of one authoritative server per record | Glue, the address records a parent zone holds for name servers inside the child, uses ordinary `A` and `AAAA` records. How `SOA` and `NS` define authority and delegation is the zones-and-delegation subject. ## What you can do instead | Option | How it works | Trade-off | |---|---|---| | `A`/`AAAA` at the apex | publish addresses directly | you must track the target's addresses when they change | | Apex redirects to `www` | apex `A`/`AAAA` point at a small web redirector; `www` is the `CNAME` | the redirect is HTTP, so it only helps web traffic | | Provider flattening (ALIAS/ANAME) | the authoritative server resolves the target and answers with synthesized `A`/`AAAA` | non-standard and provider-specific; the answer reflects the provider's view of the target | A `DNAME` does not help either: it aliases the names **beneath** its owner, not the owner itself. ## What happens if you try anyway Many authoritative server implementations refuse to load a zone with a CNAME beside other data. If such a zone were served, caches would behave inconsistently, exactly the outcome the RFC 1034 rule was written to prevent: a cache holding the CNAME may answer an `MX` or `TXT` query for `example.com` from the alias target, so mail routing and verification can silently switch to the target's records. ## Related "no alias here" rules - The name inside an `MX` or `NS` record must not be an alias (RFC 2181 §10.3). - The value of a `PTR` record must not be an alias (RFC 2181 §10.2). - An `SRV` target must not be an alias (RFC 2782). All three share the same reason: those names are expected to resolve directly to address records.

  • Why can www.example.com be a CNAME when example.com cannot?
    `www` is an ordinary name inside the zone and normally holds no `SOA`, `NS` or other records, so an alias there collides with nothing. The rule still applies to it: if you later need a `TXT` or `MX` record at `www`, you must first replace the `CNAME` with address records.
  • What does a provider flattening feature give up compared with a real CNAME?
    The authoritative server resolves the target itself and serves the resulting `A`/`AAAA` records, so resolvers never see the alias. The answer reflects where the provider resolved the target, target changes arrive only as the provider refreshes, and the behaviour is not portable between providers because no RFC defines it.
  • What does the SOA record at the apex actually contain?
    RFC 1035 defines seven fields: `MNAME` (the primary server), `RNAME` (the responsible mailbox), `SERIAL` (a 32-bit zone version compared with sequence-space arithmetic), `REFRESH`, `RETRY` and `EXPIRE` (secondary-server timers in seconds) and `MINIMUM`, which RFC 2308 uses, together with the SOA's own TTL, to bound how long negative answers are cached.

A CNAME is a forwarding notice on the door of an empty house: it says the occupant moved, and nothing else can be delivered there. The apex is a house that must always keep its deed and its list of caretakers inside, so it can never become an empty house with only a notice on the door.

saying these in an interview costs you the question

  • A CNAME at the apex is fine as long as the target has an A record.
  • The apex CNAME restriction is a limitation of certain DNS hosting providers.
  • ALIAS and ANAME are standard DNS record types defined by an RFC.
  • A CNAME can sit alongside MX and TXT records at the same name.
  • A name can hold several CNAME records to spread load across targets.