DNS and CDNs: apex CNAME, ALIAS and flattening

Why the apex cannot be a CNAME, what ALIAS and ANAME records do, how providers flatten them, and how to validate a CDN delegation.

The apex problem

The rules say a CNAME cannot coexist with any other record at the same name, and the apex always has NS and SOA records. So example.com cannot be a CNAME - yet a CDN wants you to point your hostname at a name it controls, so it can change addresses without you.

; this is invalid and every provider will reject it
example.com.   IN  CNAME  example.cdn-provider.net.

; these are the workarounds, all of them provider-specific
example.com.   IN  ALIAS  example.cdn-provider.net.     ; DNSimple, some others
example.com.   IN  ANAME  example.cdn-provider.net.     ; older name for the same idea
; Cloudflare and a few others call it CNAME flattening at the apex and
; publish the resolved addresses in the answer instead of the CNAME

• ALIAS and ANAME are not standard record types. They are a provider feature and they do not survive a move to a provider that does not implement them.
• Flattening means your provider resolves the target for you and republishes the addresses. It works, but it couples your apex to their resolver's health.
• A plain A record at the apex is the most portable option and the least convenient: you own the update when the CDN changes address.

Delegating to a CDN

Typical pattern with a provider that supports CNAME flattening

  apex      example.com      -> flattened to the CDN edge
  www       www.example.com  -> CNAME to example.com, or to the CDN directly
  cdn       cdn.example.com  -> CNAME to a provider edge name

  TLS: the CDN must be able to serve a certificate covering example.com
       and www.example.com, usually via a DNS-01 challenge it performs itself

  Redirect: pick one canonical hostname. If www is canonical, redirect the
            apex to www with a 301 served by the CDN, not by the origin.

1. Add the hostname in the CDN console first and wait for it to report the hostname as active.
2. Create the flattened record or ALIAS at the apex, and a CNAME on the subdomain.
3. Confirm the CDN can issue a certificate for the apex - a DNS-01 challenge needs the validation record to be publishable, which requires the zone to be served by a provider the CDN can write to.
4. Verify with dig that the apex returns addresses rather than a CNAME, and that the addresses belong to the CDN.
5. Check the response headers from the edge show the CDN's cache status, not just the origin's server header.

dig +short example.com                      # expect A records, not a CNAME
dig +short www.example.com                  # expect a CNAME chain to the edge
curl -sI https://example.com | grep -iE "server|cf-cache-status|x-cache|via"

# and confirm the certificate actually covers the apex
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

What can go wrong

• Keep a copy of the apex A records before switching to a flattened record. If flattening misbehaves, you can revert to explicit addresses in one change.
• Verify email records after every apex change. It is easy to remove an MX record while editing the apex.
• Test from more than one resolver. Flattening failures are frequently partial.

FAQ

Related

Subdomains, wildcards and delegation strategies Anycast, GeoDNS and traffic steering

Last refreshed 2026-09-18.