CNAME Flattening: Using CNAME Records at the Root Domain

You have a shiny new CDN, a load balancer, or a SaaS platform that hands you a hostname like myapp.cdn.example.net and tells you to point your domain at it with a CNAME record. That works perfectly for www.yourdomain.com. But the moment you try to do the same thing at your root domain — the naked apex, yourdomain.com with no subdomain — you hit a wall. DNS simply does not allow a CNAME at the zone apex. That is the core problem CNAME flattening was invented to solve, and if you are configuring a modern DNS host, you have probably already seen it called ANAME, ALIAS, or just flattening. This article breaks down why the restriction exists, what happens behind the scenes when flattening kicks in, how to configure it with the major DNS providers, and how to verify that everything is resolving correctly.

Why You Cannot Place a CNAME at the Zone Apex

The prohibition comes straight from RFC 1912 and the original DNS specification in RFC 1034. A CNAME record, by definition, says: "Stop here, look up this other name instead, and use whatever records you find there." Because a CNAME replaces all other records at that name, placing one at the root of your zone would conflict with the SOA and NS records that must live at the apex. Without those records, the zone cannot function at all — name servers would not know they are authoritative for the zone, and the entire delegation would collapse.

Authoritative name servers enforce this strictly. If you attempt to add a CNAME alongside an SOA or NS record, a compliant DNS implementation will reject it outright. Some older control panels will silently accept it and then serve broken responses, which is arguably worse because the failure is invisible until a resolver complains.

The practical consequence: you cannot simply point yourdomain.com at a CDN hostname the way you would for www.yourdomain.com. For years the only workaround was to hardcode IP addresses in A records, which defeats the entire purpose of using a provider that rotates or traffic-manages IPs dynamically.

What CNAME Flattening Actually Does

CNAME flattening is a DNS-server-side trick, not a change to the DNS protocol itself. When your authoritative name server receives a query for the apex domain, instead of returning a CNAME record (which would be illegal there), it resolves the target hostname on your behalf, takes the resulting A or AAAA records, and returns those IP addresses directly to the client. From the resolver's perspective it looks exactly like a normal A record response. The CNAME chain never appears in the answer section.

The key distinction from a standard CNAME is timing. With a regular CNAME, the end-user's resolver does the chasing. With flattening, your authoritative name server does the chasing at query time — or more commonly, on a short polling cycle — and caches the resolved IPs. This means the TTL the client sees is whatever your DNS provider decides to return, often 60–300 seconds regardless of the target's own TTL. That is an important operational detail covered more in the caveats section below.

Vendor Terminology You Will Encounter

• ALIAS record — Used by DNSimple, Namecheap, and some others. Functionally identical to flattening.
• ANAME record — Used by DNS Made Easy and a few legacy panels.
• CNAME Flattening — Cloudflare's term. Cloudflare also extends flattening optionally to all CNAME records, not just the apex.
• Root CNAME / Apex CNAME — Generic marketing terms you will see in hosting documentation.

All of these are implementation names for the same underlying behaviour: resolve the chain server-side, return A/AAAA records to the client.

Step-by-Step Configuration by Provider

Cloudflare

1. Log in to the Cloudflare dashboard and select your domain.
2. Go to DNS > Records.
3. Click Add record.
4. Set the type to CNAME.
5. Set the Name field to @ (the @ symbol represents the root domain).
6. Set Target to the hostname your provider gave you, e.g. myapp.cdn.example.net.
7. Cloudflare will automatically flatten this at query time. No special toggle needed — flattening is always on for apex CNAMEs.
8. Optionally enable the orange cloud (proxy) if you want Cloudflare to also front the traffic.

Cloudflare also offers a setting under DNS > Settings > CNAME Flattening that lets you flatten all CNAME records, not just the apex. Leave this on Flatten at apex unless you have a specific reason to flatten everything.

DNSimple

1. Open your domain's DNS settings in the DNSimple dashboard.
2. Click Add record.
3. Choose type ALIAS (not CNAME — DNSimple explicitly separates them).
4. Leave the Name field blank or enter @.
5. Enter the target hostname in the Content field.
6. Save. DNSimple resolves the alias from their authoritative servers and returns A records.

Route 53 (AWS)

AWS Route 53 calls their implementation an Alias record and it only works with other AWS resources: CloudFront distributions, Elastic Load Balancers, API Gateway, S3 static websites, etc. You cannot point a Route 53 Alias at an arbitrary third-party hostname.

1. In the Route 53 console, open your hosted zone.
2. Click Create record.
3. Set the record type to A.
4. Toggle Alias to Yes.
5. In the Route traffic to dropdown, choose the appropriate AWS endpoint type (e.g., Alias to CloudFront distribution).
6. Select the specific resource from the next dropdown.

If you are pointing at a non-AWS hostname, you must use a different DNS provider that supports open-target flattening, or proxy through CloudFront first.

Namecheap Advanced DNS

1. Log in to Namecheap and go to Domain List > Manage > Advanced DNS.
2. Add a new record and choose type ALIAS.
3. Set Host to @.
4. Set Value to the target hostname.
5. Save changes.

Porkbun

Porkbun supports ALIAS records natively. In the DNS management panel, add a record with type ALIAS, host set to the root (@ or blank), and the value as your target hostname. Porkbun resolves it server-side on their authoritative infrastructure.

Command-Line Verification

Once you have saved the record, verify it is resolving correctly. You want to confirm that querying the apex returns A or AAAA addresses, not a CNAME chain.

A correct response looks like one or more IP addresses:

If you see a CNAME record in the answer, something went wrong — either your provider did not flatten correctly, or you are querying a resolver that cached a broken response. Try querying the authoritative name server directly to bypass caching:

Replace ns1.yourprovider.com with your actual authoritative name server, which you can find from:

Also check that you have not accidentally left a conflicting A record at the apex pointing to an old IP. Conflicting records with the same name and type will cause unpredictable behaviour depending on which record the provider serves first.

Checking What the Authoritative Server Returns

You can also use our DNS Lookup tool to query your apex domain and inspect exactly what record types come back. A properly flattened domain will show only A or AAAA records — no CNAME entries — in the answer section. If CNAME appears in the answer for the apex, your DNS provider is either not supporting flattening or the record type you chose was wrong (for example, accidentally adding a TXT or SOA alongside an incorrect record type).

Important Caveats and Operational Gotchas

TTL Behaviour is Different From Regular CNAMEs

With a normal CNAME, the resolver chases the chain and honours each hop's TTL. With flattening, your DNS provider controls the TTL that clients see. Cloudflare, for instance, often returns a TTL of 300 seconds for flattened records regardless of what the CDN's A records advertise. This means IP failover from your CDN may take longer than expected to propagate because resolvers are caching the flattened IPs for your provider's chosen TTL interval, not the CDN's.

Check your provider's documentation for their polling interval — how often they re-resolve the target hostname. Cloudflare re-resolves frequently (roughly every 5 minutes for active zones). DNSimple and others vary. If your CDN changes IPs for failover, factor this polling interval into your incident response planning.

GeoDNS and Anycast Conflicts

Some CDNs use GeoDNS to return different A records to resolvers in different regions. When your DNS provider flattens by querying the target from a fixed set of resolver IPs (often in a single region), you may get IPs optimised for your provider's location, not your end user's location. This can undermine the CDN's traffic steering. Check whether your provider resolves from multiple PoPs or a centralised resolver pool — Cloudflare handles this well due to its anycast architecture, but smaller providers may not.

IPv6 Support

Make sure your provider also flattens AAAA records if your CDN or load balancer target supports IPv6. Some DNS panels require you to add a separate ALIAS/ANAME record for the AAAA type, or they automatically resolve both. Confirm with a dig on the AAAA type:

Email MX Records Still Work

A common misconception is that apex CNAME records break email. Because flattening returns A records rather than a CNAME, the standard CNAME-and-MX conflict does not apply. Your MX, SPF, DKIM, and DMARC records at the apex are unaffected. If you were using a true (illegal) CNAME at the apex with a provider that allowed it anyway, you would indeed break MX lookups — but flattening avoids this entirely.

When You Cannot Use Flattening

If your DNS provider does not support any form of ALIAS, ANAME, or flattening and you are not ready to switch providers, you have a few fallback options:

• Redirect www to root — Reverse the common approach. Serve your site at www.yourdomain.com (which can have a real CNAME) and redirect the apex to www with a 301. Many hosting platforms and CDNs provide a dedicated redirect service for the naked domain.
• Hardcode IP addresses — If your provider guarantees static IPs (some load balancer or dedicated server setups), add those directly as A records. Monitor for IP changes manually or via monitoring tools.
• Move to a provider that supports flattening — This is the cleanest long-term solution. Cloudflare's free tier includes full CNAME flattening, making it a practical choice even if you only use it for DNS.

How to Prevent Problems Going Forward

Before signing up with a hosting provider, CDN, or SaaS platform that requires a CNAME, confirm that your DNS host supports apex flattening. Ask specifically: do they support ALIAS or ANAME records at the zone root, or CNAME flattening at the apex? A vague answer about "CNAME support" is not enough — standard CNAME at the apex is not the same thing.

Document the polling interval your provider uses and build that into your runbook for incidents. If your CDN fails over and swaps IP addresses, the time for that change to propagate through your flattened DNS is the polling interval plus your provider's TTL, not just the CDN's own TTL.

Set monitoring on the apex domain's resolved IPs, not just HTTP status codes. Tools like synthetic monitoring services can alert you when the flattened A record changes unexpectedly, which might indicate your DNS provider resolved the target from a stale cache or a different geographic location than expected.

Finally, keep your zone's NS records clean. Flattening only works reliably when your authoritative name servers are the ones configured at your registrar. If you have mixed or stale NS delegations pointing at old providers, queries may hit servers that do not support flattening and return errors or incorrect record types.