CNAME Flattening Explained

Managed hosting platforms usually give customers a target hostname rather than a permanent IP address. That is a natural fit for www.example.com CNAME project.host.example, but it becomes awkward at example.com, the zone apex.

CNAME flattening and provider-specific Alias features solve that apex problem by following a target inside the authoritative DNS service and returning address records to the resolver. The public answer looks like A or AAAA data even though the operator configured a hostname target.

Why an ordinary apex CNAME conflicts with DNS

RFC 1034 defines a CNAME owner as an alias and says no other data should be present at that node. A zone apex necessarily has authority data such as SOA and NS records. Putting an ordinary CNAME at that same name would violate the single-purpose CNAME rule.

This is valid at a normal subdomain:

www.example.com.  300  IN  CNAME  project.host.example.

This is not a portable standards-compliant apex configuration:

example.com.      300  IN  CNAME  project.host.example.
example.com.      3600 IN  NS     ns1.dns-provider.example.
example.com.      3600 IN  SOA    ns1.dns-provider.example. hostmaster.example.com. ...

The apex still needs its NS and SOA data, so DNS providers expose other configuration models instead of serving that ordinary CNAME RRset on the wire.

If the difference between address records and normal aliases is still unclear, start with DNS A records versus CNAME records.

Flattening changes the answer, not the application

With Cloudflare CNAME flattening, the authoritative service resolves the configured CNAME chain and returns the final addresses instead of returning the CNAME record itself.

An operator might configure this in the dashboard:

Name:    example.com
Type:    CNAME
Target:  external-origin.example.net
Proxy:   DNS only
TTL:     3600

The public resolver can receive:

example.com.  3600  IN  A     192.0.2.18
example.com.  3600  IN  A     192.0.2.19
example.com.  3600  IN  AAAA  2001:db8::18

For a DNS-only Cloudflare record, the flattened addresses come from the external target; Cloudflare documents the resulting TTL as the lower value of the configured CNAME TTL and the external answer’s TTL. A proxied record behaves differently: the public answer contains Cloudflare anycast addresses and the origin target stays behind the proxy.

Neither case configures the hosting project for example.com. The provider still has to accept the custom domain, route the Host header, and issue a certificate for the apex.

CNAME, flattening, Alias, and ANAME are not interchangeable terms

Dashboard concept	What is standardized on the wire	Apex capable	What public dig shows
Ordinary CNAME	CNAME RR type	No	The target hostname, followed by resolution as needed
Cloudflare flattened CNAME	Provider follows a configured CNAME and synthesizes address answers	Yes	A/AAAA answers; proxied records show Cloudflare addresses
Route 53 Alias	AWS-specific extension attached to an A/AAAA-style record	Yes for supported targets	A/AAAA answers; Alias metadata is visible in Route 53 configuration, not as an Alias RR
Provider ALIAS or ANAME label	Provider-specific behavior	Depends on provider	Usually synthesized A/AAAA answers; verify the provider contract

The IANA DNS resource-record registry assigns a type code to CNAME but does not define general-purpose ALIAS or ANAME RR types. A dashboard using those words is describing a provider feature, not a portable zone-file record. Export behavior, supported targets, TTL handling, health evaluation, and DNSSEC interaction can therefore differ.

Route 53, for example, limits Alias targets to supported AWS resources or eligible records, while an ordinary CNAME can point to a hostname in another DNS service. Do not copy an ALIAS configuration from one provider into another dashboard and assume the semantics transfer.

Keep configuration evidence because the public answer hides intent

After flattening, this check may correctly return nothing:

dig example.com CNAME +short

The absence of a public CNAME answer does not prove that the configured target disappeared. Query the address types:

dig example.com A +short
dig example.com AAAA +short

Then keep provider-side evidence of the target:

• a version-controlled DNS declaration when infrastructure-as-code is available
• a zone export or API response
• the hosting platform’s accepted custom-domain record
• the expected target hostname and rollback target
• proxy and flattening settings

This distinction matters during incidents. Public DNS answers show where the target resolves now; provider configuration shows which target the operator intended to follow.

Illustrative flattening record

The image below demonstrates a configured hostname target beside synthesized public address answers. It is not a capture from a live DNS account.

Illustrative example using reserved example domains and IPs.

Verification needs four layers

1. Confirm the authoritative configuration

Record the configured hostname target, not only the final IP. If the target has a typo or no A/AAAA data, Cloudflare documents that flattening can return an empty answer (NODATA) because there is no address to synthesize.

2. Compare public address families

dig @1.1.1.1 example.com A +short
dig @1.1.1.1 example.com AAAA +short
dig @8.8.8.8 example.com A +short
dig @8.8.8.8 example.com AAAA +short

Check both A and AAAA. An unexpected IPv6 answer can send some visitors to a different or stale origin even when IPv4 looks correct.

3. Confirm host binding and TLS

curl -I https://example.com
openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

A valid DNS answer with the wrong application or a certificate that covers only www is still a failed apex rollout.

4. Inspect redirect behavior

Decide whether the apex is canonical or redirects to www. Follow the complete chain and reject loops or hops through an old platform:

curl -sS -o /dev/null -L \
  -w '%{http_code} %{url_effective} %{num_redirects}\n' \
  https://example.com/

Do not flatten verification CNAMEs blindly

Some vendors verify domain ownership by querying for a literal CNAME token. Cloudflare warns that proxying or flattening that record can make verification fail because the CNAME itself is no longer returned directly.

For verification records:

• keep the record DNS-only when the vendor requires a CNAME answer
• disable per-record flattening
• avoid zone-wide “flatten all CNAMEs” unless every verification workflow has been checked
• verify the exact record type with dig token.example.com CNAME

This is a reason to apply flattening narrowly. Apex flattening solves a specific DNS constraint; it does not need to become the default for every alias in the zone.

Migration and rollback runbook

Treat a flattened apex migration like an origin change:

1. Add and validate example.com in the destination platform before changing DNS.
2. Record the old A/AAAA values, target, proxy mode, and TTL.
3. Lower operator-controlled TTLs ahead of the maintenance window where useful.
4. Configure the provider’s supported apex feature with the documented target.
5. Verify authoritative configuration, public A and AAAA answers, TLS, host binding, and redirects.
6. Monitor HTTP errors and certificate issuance through at least the previous cache window.
7. Roll back using the recorded configuration if the platform rejects the host or the target resolves incorrectly.
8. Remove stale address records and old platform bindings only after the new path is stable.

DNS cache behavior can make old and new answers coexist during the change; the DNS propagation guide explains how to separate authoritative state from cached state.

Finally, include apex targets and provider-specific aliases in the public hostname inventory. Flattening is maintainable when the public address answer, hidden configured target, application binding, and rollback path are all recorded together.