Why can't you put a CNAME at the zone apex? ALIAS, ANAME and CNAME flattening explained

The rule, and why it isn’t optional

A domain’s apex — the bare name itself, like example.com with nothing in front of it — has to carry two things for the zone to work at all: an SOA record identifying the zone’s authority, and the zone’s NS records naming its nameservers, both required by RFC 1035 §3.3.13 and the surrounding zone-file rules. RFC 1034 §3.6.2 separately states that if a CNAME record exists at a name, no other record should exist there. Put those two requirements together and a real CNAME at the apex is excluded by the standard itself, not by any individual DNS provider’s dashboard being unhelpful — the apex must carry SOA and NS, and a CNAME can’t share a name with anything else. RFC 2181 §10.1 reinforces the same coexistence rule for CNAME resource records generally.

This is exactly why you can point www.example.com at a CDN or hosting platform with a plain CNAME, but the moment someone asks for the bare example.com to go to the same place, every DNS provider’s interface refuses — not out of caution, but because the record you’re asking for isn’t valid DNS.

What ALIAS, ANAME and CNAME flattening actually do

Several DNS providers offer a workaround, under names like ALIAS, ANAME, or “CNAME flattening,” that gets the same practical result — the apex follows a target hostname whose address can change — without violating the rule above. None of these is a standardized resource record type defined in any RFC; each is a provider-specific feature implemented entirely on the authoritative nameserver’s side. When a query comes in for the apex, the provider’s own infrastructure resolves the configured target hostname itself, then answers the query with a plain A or AAAA record containing whatever address that resolution returned. From the outside, on the wire, it looks exactly like an ordinary A/AAAA answer — because that’s literally what gets sent. No new record type, no indication in the response that anything other than a static address record was ever involved.

This is a meaningful distinction from a real CNAME: a CNAME tells the querying resolver to go look up another name itself, which is the behavior RFC 1034 and RFC 1035 define. ALIAS/ANAME/flattening does that lookup on the authoritative side, before answering, specifically so the apex can still present a plain, standards-legal A/AAAA record to the outside world.

Why this matters beyond “it technically works”

Because the mechanism isn’t standardized, its exact behavior is whatever each provider decided to build, and that varies in ways worth knowing before you rely on it:

• Update timing isn’t governed by any spec. A real CNAME’s freshness is governed by its own TTL, which every resolver honors the same way. An ALIAS/ANAME record’s update timing depends on how often that specific provider’s infrastructure re-resolves the target — some track the target’s TTL closely, others re-check on their own schedule — and that detail lives in the provider’s documentation, not in any RFC.
• It’s provider-specific, not portable. A zone exported from one provider’s ALIAS feature has no standard on-the-wire representation to import into a different provider; the receiving provider needs its own equivalent feature, or the apex has to fall back to a plain static A/AAAA record instead.
• It’s invisible to a plain DNS query. Querying the apex with AdminKit’s DNS lookup tool (or any resolver) returns a normal-looking A/AAAA answer either way — there is no flag in the DNS response distinguishing “this is a static record” from “this was synthesized by ALIAS flattening a moment ago.” Confirming which one you actually have means checking your provider’s own zone configuration, not a public lookup.

If you don’t have ALIAS/ANAME available

Not every DNS provider offers this feature. The two common fallbacks are pointing the apex at a static IP address with a plain A/AAAA record (losing the ability to follow a target that changes its own address) or moving the zone to a provider that does support ALIAS/ANAME/flattening. Either way, the underlying rule doesn’t change: whatever ends up at the apex has to be a record type RFC 1034 and RFC 1035 actually allow to coexist with the zone’s required SOA and NS records, and a CNAME is never that record.

Checking your own apex

Run AdminKit’s DNS lookup tool against your bare domain with the A (or AAAA) record type selected to see exactly what address it currently resolves to — the same check works whether that address came from a static record or a flattened alias, since both answer identically on the wire. If you’re also auditing whether a subdomain mistakenly points at a CNAME somewhere it shouldn’t, see when an MX record points to a CNAME for the mail-specific version of this same coexistence rule, and how to read a DNS lookup result for what each record type in a lookup actually means.

Two other configuration details worth checking while you’re reviewing DNS and TLS fundamentals: whether your certificate setup actually matches the hostnames you think it covers, in wildcard vs SAN certificates explained, and whether your DMARC record’s alignment setting matches how your mail is actually sent, in DMARC alignment: relaxed vs strict explained.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.