Why ALIAS, ANAME, and CNAME Flattening Matter for CloudFront, CDNs, and Multi-Tenant SaaS

If you’ve ever tried to point a root domain like example.com directly at CloudFront, Fastly, or another CDN, you’ve probably hit a weird wall:

“I just want a CNAME at the root. Why is this so hard?”

The short version: the DNS spec says you can’t put a CNAME at the zone apex, and modern CDNs usually only give you a hostname, not a fixed IP. ALIAS, ANAME, and “CNAME flattening” are provider-specific tricks that bridge that gap so you can still point your root domain at a CDN or SaaS platform.

This article walks through:

• Why apex CNAMEs are a problem
• How ALIAS / ANAME / flattening actually work
• When you really need them (CloudFront & multi-tenant SaaS are big ones)
• A practical list of DNS providers that do — and don’t — help you here

The core problem: CNAME at the apex is forbidden

DNS has a couple of important rules:

• The zone apex (example.com) must host critical records like SOA and NS, and usually others like MX.
• A CNAME record basically says, “this name is just an alias, don’t look for any other records here.”

The DNS standards say: for any given name, you can either have a CNAME or other records, but not both.

Since the apex has to have SOA/NS (and often MX), it cannot legally be a CNAME. That’s why traditional DNS UIs won’t let you create a CNAME on @ (the root).

But modern infrastructure (CloudFront, other CDNs, many SaaS platforms) often only give you a hostname like:

Those providers:

• Don’t expose fixed IPs (they use anycast + lots of dynamic edges).
• Expect you to use a CNAME from your domain to their hostname.

That works great for subdomains (www.example.com, api.example.com), but not for the apex (example.com) because of the CNAME rule.

That’s the tension ALIAS/ANAME/flattening solve.

How ALIAS, ANAME, and CNAME flattening fix it

Different DNS providers invented slightly different solutions. They all work on the same basic idea:

At query time, the DNS provider chases the CNAME for you and returns A/AAAA records, so resolvers never see the CNAME conflict at the apex.

Conceptually:

1. You configure something like:
   • example.com ALIAS d1234abcd.cloudfront.net
2. When a resolver asks for example.com, your DNS provider first resolves d1234abcd.cloudfront.net to current IPs.
3. It then responds with A/AAAA records for those IPs, not with a CNAME.

To the outside world, it looks like a normal A record — but you get all the convenience of pointing at a hostname that can change over time.

Names you’ll see in different UIs:

• ALIAS – commonly used by DNSimple, Namecheap, and others.
• ANAME – commonly used by DNS Made Easy, easyDNS, and others.
• CNAME Flattening – Cloudflare’s term for automatically resolving a CNAME at the apex and returning A/AAAA instead.
• Alias records – Azure DNS and some other platforms use this generic label.

These are proprietary / non-standard record types; they’re not defined in RFCs, but widely implemented by DNS providers to handle CDNs and SaaS platforms cleanly.

When you actually need ALIAS/ANAME/flattening

There are a few common patterns where these become essential:

1. CDNs (CloudFront, etc.) on the root domain

Most CDNs (including Amazon CloudFront) hand you a hostname — which may be anycasted or change IPs frequently. For subdomains, you just:

But if marketing insists on naked-domain only (https://example.com/), you need one of:

• example.com ALIAS / ANAME / flattened CNAME → d1234abcd.cloudfront.net, or
• A CDN / load balancer that offers static IPs (often with extra complexity/cost).

Without that, you’re stuck manually copying IPs (bad and brittle) or forcing everyone through www + redirects.

2. Multi-tenant SaaS with customer root domains

If you’re running a SaaS where customers bring their own domain, they’ll often want customer.com, not just app.customer.com.

Your onboarding docs will look something like:

• Recommended:
  • @ → ALIAS/ANAME/flattening → customer-id.your-saas.com
  • or
  • @ → HTTP redirect → www.customer.com, and www CNAME → your SaaS hostname

Customers whose DNS provider doesn’t support ALIAS/ANAME/flattening at the apex will either:

• Move DNS to a more capable provider, or
• Accept a www pattern and an HTTP redirect from the root.

3. “I just want to point my root domain at another hostname”

This shows up with:

• Hosted blog platforms
• Page builders
• Static-site hosts
• Object-storage websites (e.g., S3 website endpoints)

All the same constraints apply. If the provider only gives you a hostname, you either need apex aliasing or a www subdomain + redirect.

Who supports ALIAS/ANAME/flattening?

This is not an exhaustive list, and providers change features over time, but here are some notable examples as of late 2025.

DNS providers that support apex aliasing in some form

Cloudflare

• Feature: CNAME flattening
• Lets you configure a CNAME on the zone apex; Cloudflare resolves it and returns A/AAAA.

Amazon Route 53

• Feature: ALIAS records
• Special record type that lets you point the apex at CloudFront, ELB, API Gateway, S3 website, etc., while remaining RFC-compliant.

DNSimple

• Feature: ALIAS records
• Proprietary record type; dynamically resolves to A/AAAA and is explicitly designed for apex → hostname use.

Namecheap

• Feature: ALIAS (also sometimes referred to as ANAME)
• Supports an ALIAS record that can be used at the root to point to another hostname.

DNS Made Easy

• Feature: ANAME records
• ANAME is marketed as “a CNAME at the root,” explicitly targeted at CDNs and other hostname-only services.

easyDNS

• Feature: ANAME – “Root Domain Alias”
• Provides ANAME at the zone apex that’s flattened into A records behind the scenes.

Azure DNS

• Feature: Alias record sets for A / AAAA / CNAME
• Let you point apex records at Azure resources or other records in the zone, effectively solving the same problem for Azure workloads.

Other providers with similar features

There’s a growing list of providers that offer ALIAS/ANAME/flattening-style functionality — for example ClouDNS, CloudNS, Spaceship, and more.

Community-maintained lists (like “Which DNS Providers Support Apex CNAME Records (a.k.a. CNAME Flattening)”) are handy to check for up-to-date coverage and caveats.

Providers that don’t fully support it (or only in specific products)

Many domain registrars and shared hosting panels still don’t expose ALIAS/ANAME/flattening in their default DNS UI. Instead you’ll see only:

• A / AAAA
• CNAME (subdomains only)
• MX, TXT, etc.

Historically, Google Domains and GoDaddy’s standard DNS have been called out as not supporting apex CNAME / flattening, which is why many guides suggest moving DNS to Cloudflare or Route 53 when you need to point the root at a CDN.

More recently, some GoDaddy product-specific DNS offerings (for example, Managed WooCommerce hosting) have introduced CNAME flattening options — but that doesn’t automatically mean every GoDaddy DNS zone has ALIAS/ANAME-style features available.

Because this space changes quickly, the safest guidance for your customers is:

Open your DNS provider’s docs or zone editor and look for a record type called “ALIAS,” “ANAME,” “Apex Alias,” “CNAME flattening,” or “Alias record”. If you don’t see any of those, assume your provider does not support apex aliasing.

If that’s the case, the usual options are:

1. Use www + redirect
   • example.com → HTTP/301 redirect → www.example.com
   • www.example.com CNAME your-cdn-hostname
2. Move DNS to a more capable provider
   • Keep the domain registered where it is, but delegate DNS to Cloudflare, Route 53, DNSimple, etc.

Practical guidance for teams (and customers)

If you’re running CloudFront or any multi-tenant SaaS where customers bring their own domains, here’s a simple decision tree you can put in your docs:

1. Is the customer okay using www?
   • Yes → Use www CNAME to your hostname; redirect example.com → www.example.com. No apex aliasing needed.
   • No → Continue.
2. Does their DNS provider support ALIAS / ANAME / CNAME flattening / alias records at the apex?
   • Yes → Document exactly what they should create:
     • @ → ALIAS/ANAME/flattening → customer-id.your-saas.com
   • No → Give them a choice:
     • Move DNS to a provider that does; or
     • Accept a www pattern with redirects.
3. For your own domains (company sites, product sites):
   • If you’re already in Cloudflare, Route 53, DNSimple, DNS Made Easy, etc., use their native apex aliasing features.
   • If you’re using a registrar DNS that doesn’t support it, consider delegating DNS to one that does, while keeping registration where it is.

Wrap-up

ALIAS, ANAME, and CNAME flattening exist because DNS is old and CDNs are new:

• The DNS spec bans CNAMEs at the apex.
• CDNs and many SaaS platforms want you to point at a hostname, not an IP.
• ALIAS/ANAME/flattening simulate “CNAME at the root” by resolving the hostname on the DNS side and answering with A/AAAA records.

For teams running CloudFront or multi-tenant apps, that’s the difference between:

• Fighting DNS every time a customer wants https://customer.com, or
• Having a clean, repeatable pattern that “just works.”

If you’d like help designing or operating a DNS/CDN strategy that works well with multi-tenant applications, the Reliable Penguin team is happy to talk.