CNAME at the Apex Domain: Why It Fails and How Flattening Fixes It

You sign up for a hosting platform, and its instructions say "point your domain to myapp.platform.com with a CNAME". You open your DNS panel, try to add a CNAME for example.com, and the panel refuses. That is not a bug in your provider. It is a rule of the DNS protocol, and understanding it explains the workarounds: ALIAS, ANAME and CNAME flattening. This guide covers why the rule exists, what each workaround does under the hood, and how to pick and verify one. For general record types, see DNS explained for website owners.

Why a CNAME cannot sit at the apex

The apex (also called the root, naked or bare domain) is the zone name itself: example.com. A CNAME means "this name is an alias for another name; whatever you would find at the target, use it for me". The standard (RFC 1034, restated in RFC 2181) says that if a name has a CNAME, it cannot have any other record types. The alias must be the only data for that name.

The apex always has other records, and they are mandatory:

• An SOA record that defines the zone
• NS records that delegate it
• Usually MX for email, TXT for SPF and verification, and CAA

A CNAME at the apex would conflict with all of them. The resolver would not know whether to treat the SOA and NS records as part of the zone or as part of the alias target, and the zone would be broken. Subdomains such as www.example.com have no such mandatory records, so a CNAME there is fine.

This is also why some DNS providers let you create the record and then cause silent breakage: mail delivery fails because MX lookups at the apex return the CNAME target's data. If you ever see a zone with both a CNAME and MX at the same name, treat it as a defect and fix it.

What the problem looks like in the wild

• The DNS panel says "CNAME records cannot be created at the root" or "conflicts with other records".
• Email stops after someone adds a CNAME to the apex at a provider that did not block it.
• You publish www.example.com correctly but example.com returns nothing, or goes to a registrar parking page.
• A platform gives only a hostname target (common with PaaS, CDNs, and some site builders), not an IP address, because the IPs change.

The reason platforms give hostnames is that they need to move your traffic between servers or regions without asking you to edit DNS. A static A record would undo that.

The workarounds

All three techniques below produce the same visible result: a query for example.com returns plain A (and AAAA) records. They differ in who does the lookup and when.

CNAME flattening

The authoritative DNS provider resolves the CNAME target itself and answers with the final A/AAAA records as if they were set directly on your name. To the outside world there is no CNAME at all, just addresses, so it never conflicts with SOA, NS or MX. Cloudflare calls this CNAME flattening and applies it automatically at the apex. Cloudflare also lets you enable it for all CNAMEs in a zone, depending on plan; check the provider's documentation for current options.

ALIAS record

ALIAS is a provider-specific record type that behaves like a CNAME but is allowed at the apex. The provider's nameserver resolves the target on demand (or periodically) and serves addresses. Names and behavior differ by provider: DNSimple, DNS Made Easy, and Route 53 (as an "Alias" record pointing to AWS resources only) all offer variants. In Route 53, alias records can target AWS resources such as CloudFront distributions, load balancers and S3 website endpoints, and answers are free of charge for AWS alias targets; it cannot point at an arbitrary external hostname.

ANAME

ANAME is a proposed standard record type (an IETF draft) used by some providers, with the same idea as ALIAS: a CNAME-like pointer that the authoritative server resolves and answers with addresses. Some providers use the label "ANAME" for what is functionally ALIAS. Because it is not a finalized standard, treat the label as a provider feature, and do not expect the record to move between providers unchanged.

Quick comparison

Trade-offs you inherit

Flattening and ALIAS are convenient, but they change how DNS behaves in ways worth knowing:

• Geo-routing and CDNs may get the wrong answer. When you resolve a CDN hostname from the DNS provider's servers, the CDN returns addresses chosen for the provider's location, not the visitor's. With resolver-based or EDNS Client Subnet routing, results can be less optimal. Large CDNs and some providers handle this specially; test from different regions.
• TTL behavior. The TTL in the answer is typically the lower of your record TTL and the target's TTL, or a fixed value chosen by the provider. See TTL explained for how that plays into change planning.
• Stale addresses. If the provider refreshes the target periodically, the address in your answer can lag a change at the target. Most providers refresh at least as often as the target's TTL, but ask.
• Provider lock-in. ALIAS and ANAME are not portable. When you move DNS hosts, recreate the equivalent or use an A record to the platform's documented IPs.
• DNSSEC. Flattened answers have to be signed by your provider on the fly. Providers that support both generally handle this, but confirm before enabling DNSSEC with flattening. See DNSSEC explained.
• Troubleshooting is harder. dig example.com CNAME returns nothing, because there is no CNAME in the response. Look at A and AAAA instead and check the provider dashboard for the configured target.

Alternatives that avoid the problem

1. Use www as the canonical hostname. Point www at the platform with an ordinary CNAME, and redirect the apex to it. The apex still needs an address to answer, so use your registrar's redirect service or a small host that returns a 301. Details of redirect types are in the redirects guide.
2. Use the platform's published IP addresses. Many platforms document stable IPs for apex records (for example, a set of A and AAAA records). If they promise they will not change, a plain A record works. If they change them, you will not find out until the site breaks.
3. Move DNS to a provider with flattening. Changing nameservers is safe if you prepare; follow change nameservers without downtime.
4. Use an A record to your own reverse proxy or load balancer that you control, and let it forward to the platform.

Setting it up: a worked example

Suppose you host on a platform that gives you myshop.platform-example.net and you want both www.example.com and example.com to work.

1. In DNS, create www as a CNAME to myshop.platform-example.net.
2. For the apex, choose one:
3. Cloudflare: add a CNAME named @ pointing to the same target. Cloudflare will flatten it automatically.
4. Route 53 and a CloudFront/ELB target: create an A record in Alias mode and choose the AWS resource.
5. DNSimple or similar: create an ALIAS record named @.
6. No support: add A/AAAA records with the platform's documented IPs, or use a redirect.
7. Check that @ still has your MX, TXT and CAA records. They live alongside the flattened or alias record.
8. Add the domain in the platform's dashboard so it provisions a certificate for both names. See SSL certificate types explained and Let's Encrypt renewal failures if certificate issuance stalls.

Verifying your setup

# What do public resolvers return for the apex?
dig +short example.com A @1.1.1.1
dig +short example.com AAAA @8.8.8.8

# Is there (incorrectly) a CNAME at the apex? Should be empty on a flattened setup
dig +short example.com CNAME

# Confirm mail and other records survived
dig +short example.com MX
dig +short example.com TXT

# www should show a real CNAME chain
dig www.example.com

Use the DNS checker for a multi-location view and the website hosting checker to see which provider the answer belongs to. If the answer reaches a CDN, the CDN detector confirms it.

A related risk: dangling targets

Every CNAME or alias to a platform hostname is a promise that the platform still has your tenant. If you cancel the project and leave the record, someone else may claim that hostname and serve content on your domain. Audit with the dangling DNS checker and read subdomain takeover and dangling DNS.

Next steps

• Check what your apex returns with the DNS checker and the nameservers with the nameserver lookup.
• Review past changes in the DNS history tool.
• Scan for abandoned platform targets with the dangling DNS checker.
• Keep the full record reference handy: DNS records cheat sheet.

FAQ

Is ALIAS the same as CNAME?

Not quite. A CNAME is a real DNS record type that clients see and follow. An ALIAS is a provider feature that returns plain address records, so clients never see the alias.

Will flattening break my email?

No. Because answers contain only A/AAAA records, MX, TXT and other apex records are unaffected. The break happens when someone adds a true CNAME at the apex.

Why does dig show no CNAME for my flattened domain?

Flattening happens inside the authoritative server. The response contains the final addresses only, so there is no CNAME to display. Look at the provider's dashboard for the configured target.

Should I redirect the apex to www instead?

It is a reasonable choice when your provider has no flattening. Pick one canonical hostname, redirect the other with a 301, and make sure both names have valid certificates.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.