CNAME flattening is a DNS-provider feature that follows a CNAME target on your behalf and returns the target’s final A or AAAA addresses under the name you queried.

The public resolver receives address records instead of the CNAME chain.

Providers commonly use this technique at the zone apex: the bare domain such as example.com. It lets you point that name to a cloud platform or load balancer hostname while retaining the DNS records that the apex already needs.

A typical configuration and answer look like this:

Stored with the DNS provider:
example.com  CNAME  origin.host.example

Returned to a public resolver:
example.com  A      192.0.2.10
example.com  AAAA   2001:db8::10

The first line describes provider-side intent. The second pair describes the public DNS answer. The provider has “flattened” the hostname chain into addresses.

Why the zone apex creates a problem

A standard CNAME makes one DNS name an alias of another. The RFC 1034 rule says a CNAME node should not contain other data.

That rule conflicts with the apex. Every DNS zone needs SOA and NS data there. Many domains also use MX records for email and TXT records for verification or policy. A literal CNAME at the same name would collide with those records.

The problem appears when a hosting platform gives you a hostname instead of a fixed address:

origin.host.example

You can place that target in a normal CNAME at www.example.com. You normally cannot place a standard CNAME at example.com. If you need the broader distinction first, read our A versus CNAME explanation.

CNAME flattening moves the alias step inside the authoritative DNS provider. The provider keeps the required apex records and sends ordinary A or AAAA answers to the outside world.

How CNAME flattening works

The mechanism adds one provider-side resolution step.

1. A recursive resolver asks the authoritative provider for example.com A or example.com AAAA.

2. The provider finds the stored hostname target, such as origin.host.example.

3. The provider resolves that target and follows any additional CNAMEs until it reaches address records.

4. The provider returns those addresses with example.com as the owner name.

5. The resolver caches the answer according to the effective TTL.

The target platform can change its addresses without asking you to replace a static A record. Your DNS provider refreshes its answer from the hostname target according to its own implementation and cache rules.

This process does not redirect the browser. The address bar stays on example.com, and the browser sends its HTTP request only after DNS resolution. You need an HTTP redirect when you want the visible URL to change.

What a resolver can see

A resolver normally sees the CNAME in a standard CNAME response. A flattened answer hides that intermediate record and exposes the final address data.

I ran current DNS queries on 29 August 2026. www.github.com returned a visible CNAME target, followed by an IPv4 address. truehost.co.uk returned A and AAAA addresses and no CNAME answer.

The result shows two public answer shapes. It does not reveal the private Truehost zone configuration.

That limit matters. A public A or AAAA answer cannot tell you whether the operator configured:

• ordinary A and AAAA records;

• a flattened CNAME;

• an ALIAS or ANAME feature;

• an Amazon Route 53 alias; or

• a proxied provider record that returns the provider’s addresses.

To prove the configuration, inspect the authoritative provider’s control panel or API as well as the public answer.

CNAME flattening, ALIAS and provider aliases

These features solve similar problems, but they do not create one universal DNS record type.

Feature	What you configure	Apex support	Public answer	Important limit
Standard CNAME	Standard CNAME target	Normally no	CNAME remains visible	Cannot coexist with ordinary data at that name
CNAME flattening	CNAME-like hostname target	Provider dependent	A and/or AAAA	Behaviour and controls belong to that provider
ALIAS or ANAME	Proprietary virtual record	Usually yes	A and/or AAAA	Name and refresh rules vary by provider
Route 53 alias	AWS-specific alias property	Yes for supported targets	Chosen record type, often A/AAAA	Target choices follow Route 53 rules

Cloudflare says it always flattens a CNAME at the apex. Its current flattening guide also offers broader flattening controls in supported configurations.

DNSimple describes ALIAS as a proprietary virtual record that dynamically resolves its target and returns A or AAAA records.

Amazon calls its equivalent an alias record, restricts it to supported resources or records, and keeps the alias property outside the public DNS answer.

Do not choose a record label from another provider’s guide. Use the exact apex-alias feature that your authoritative DNS service supports.

When CNAME flattening helps

Use a supported flattening or alias feature when all three conditions apply:

• you need the bare domain to reach the service;

• the service gives you a hostname rather than stable IP addresses; and

• your authoritative DNS provider supports the required apex feature.

This pattern suits hosted applications, CDNs and load balancers whose addresses can change behind a stable target hostname.

Netlify, for example, recommends ALIAS, ANAME or flattened CNAME support for its apex load-balancer target in its external DNS guide.

You do not need flattening when the platform gives you stable addresses and explicitly requests A or AAAA records.

You also do not need it for an ordinary subdomain CNAME unless your provider or application requires a flattened response there.

Failure modes to check

The target has no addresses

If the final hostname has no A or AAAA data, the provider has nothing to return. Cloudflare documents a NODATA response for a dangling flattened target.

This can look like failed propagation even though the stored target itself has propagated.

Query the target hostname directly. Fix that target or replace it with the hostname the platform currently supplies.

Flattening hides a verification CNAME

Some services verify ownership by querying a CNAME and comparing the visible target. Flattening that record can return addresses instead, so the verifier never sees the expected CNAME.

Cloudflare specifically warns that enabling flattening for all CNAMEs can disrupt this pattern.

Keep verification records such as provider-specific tokens or DKIM selectors unflattened unless the service says otherwise.

IPv4 works but IPv6 does not

A target may return A records without AAAA records, or your provider may handle the two families differently. Test both. Do not assume that a working A answer proves IPv6 support.

Cache timing masks a target change

The target and your provider each have TTL and cache behaviour.

Cloudflare states that an unproxied flattened response uses the lower of the external target TTL and its CNAME TTL. Other providers may use different refresh and failure policies.

Record the TTL you actually receive and allow existing caches to expire before diagnosing a stale answer as a permanent fault.

The feature does not move with your nameservers

Flattening, ALIAS and provider aliases often exist only inside the provider that implements them. A zone export may contain synthesised A/AAAA records or may omit the proprietary rule entirely.

Before changing nameservers, recreate the equivalent feature at the new provider and test it. Do not assume a zone transfer can carry a non-standard record unchanged.

How to test CNAME flattening

First, confirm which nameservers are authoritative. Then compare the public record classes.

Resolve-DnsName example.com -Type CNAME -DnsOnly
Resolve-DnsName example.com -Type A -DnsOnly
Resolve-DnsName example.com -Type AAAA -DnsOnly

On systems with dig:

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

A working flattened setup commonly produces no CNAME answer and one or more A or AAAA answers. That result proves the public response shape, not the stored rule.

Complete the check in this order:

1. Confirm the hostname target in the DNS provider’s current control panel.

2. Resolve the target directly and verify that it has the expected addresses.

3. Query CNAME, A and AAAA for your apex through a public resolver.

4. Query an authoritative nameserver directly when you need to separate authoritative data from recursive cache.

5. Open the site over HTTPS and confirm that the certificate covers the apex.

6. Recheck MX, TXT and other apex records that must remain available.

Do not stop after the browser loads once. A cached address can hide a broken target, while a DNS success cannot prove that the web server recognises your hostname or presents the right TLS certificate.

Use the feature your DNS provider documents

CNAME flattening solves a narrow problem: your apex needs to follow a hostname target, but a standard CNAME cannot occupy that name alongside required DNS data. The authoritative provider follows the target and gives public resolvers an A/AAAA-shaped answer.

Keep the terms precise. Cloudflare flattening, DNSimple ALIAS and Route 53 aliases share a goal but differ in configuration, supported targets, TTL handling and migration behaviour.

If you are registering or moving a domain, use our domain search and confirm the DNS feature your intended hosting platform requires before changing the apex.

For the full connection workflow, use our domain pointing guide.

---