What Is CNAME Flattening, and Why Does It Matter for Root Domains?

Normal DNS resolution splits the work in two. Your authoritative nameserver says "www.example.com is really myapp.example-cdn.net," and the visitor's recursive resolver goes off and chases that name to an IP address. CNAME flattening moves the chase to the other side: the authoritative server follows the chain itself and hands back only the final addresses. That small shift is what lets you point a root domain at a hostname, but it also changes who does the lookup, from where, and with which TTL, and those changes have real consequences. This article walks through the flattening mechanism step by step, shows what it looks like on the wire, and explains the trade-offs you are accepting when you rely on it. If you want the background on how resolvers normally chase records, see What Is the Role of a DNS Resolver?

What Is CNAME Flattening?

CNAME flattening is a technique where an authoritative DNS server, instead of returning a CNAME record to the client, resolves the CNAME target (and any further CNAMEs in the chain) and returns the resulting A and AAAA records under the original name.

The term was popularised by Cloudflare, which introduced it in 2014 and applies it automatically to CNAMEs at the zone apex. Other providers implement the same idea under the names ALIAS or ANAME. Those record types, and how each vendor exposes them, are covered in What Is an ALIAS or ANAME Record?. Here we focus on the mechanism that sits underneath all of them.

Why Root Domains Need It

A CNAME says "this name is an alias, and has no data of its own." The DNS rules therefore forbid a CNAME from sharing a name with any other record. The root of every zone, though, must hold an SOA record and NS records, and usually MX and TXT records too. So a CNAME at example.com is not allowed. The full rule and its history are explained in Can You Use a CNAME Record on the Root Domain?.

Flattening sidesteps the rule because no CNAME ever leaves the server. Resolvers see the apex holding ordinary A and AAAA records next to the SOA, NS, MX and TXT records, which is perfectly legal.

How Flattening Works, Step by Step

Here is what happens when a visitor's resolver asks for example.com and the zone contains an apex CNAME to myapp.example-cdn.net.

Without flattening (what a plain CNAME would do)

On a subdomain, where CNAMEs are allowed, the exchange looks like this:

1. The resolver asks your authoritative server for www.example.com A.
2. Your server answers: www.example.com CNAME myapp.example-cdn.net.
3. The resolver asks the CDN's authoritative servers for myapp.example-cdn.net A.
4. The CDN answers with an IP chosen for the resolver's location.
5. The resolver caches both records, each with its own TTL, and returns the IP to the visitor.

With flattening

1. The resolver asks your authoritative server for example.com A.
2. Your server sees the stored CNAME target and checks its internal cache for myapp.example-cdn.net A.
3. On a cache miss, your server performs its own recursive lookup and receives an IP chosen for your DNS provider's location (or, with client subnet support, an approximation of the visitor's).
4. Your server responds with example.com A 203.0.113.10 and a TTL it decides.
5. The resolver caches a single A record. It never learns that a CNAME existed.

You can see the difference with dig. A subdomain using a normal CNAME shows the chain:

dig www.example.com A +noall +answer

www.example.com.        300     IN      CNAME   myapp.example-cdn.net.
myapp.example-cdn.net.  60      IN      A       203.0.113.10

The flattened apex shows only the end result:

dig example.com A +noall +answer

example.com.            300     IN      A       203.0.113.10

Notice the TTLs. In the unflattened case, the CDN controls the 60-second TTL on the A record. In the flattened case, your DNS provider chose 300 seconds. That is the first of several trade-offs.

Watching the Mechanism Directly

To confirm a provider is flattening rather than serving static A records, query the authoritative server directly and compare with the target:

# Find the authoritative servers for the zone
dig example.com NS +short

# Ask one of them directly, without recursion
dig @ns1.example-dns.net example.com A +norecurse +noall +answer

# Resolve the target yourself for comparison
dig myapp.example-cdn.net A +short

The first command lists the zone's nameservers. The second asks one of them for the apex A record with recursion disabled, so you are seeing exactly what the authoritative server synthesises. The third resolves the target independently. If the authoritative answer tracks the target's IPs over time (run it a few times across several minutes), the zone is being flattened. More dig techniques like these are in How to Use the dig Command for DNS Lookups.

If you want to observe the IP rotation programmatically, this Node.js script polls both names:

import { Resolver } from "node:dns/promises";

const resolver = new Resolver();
resolver.setServers(["1.1.1.1"]);

async function snapshot() {
  const [apex, target] = await Promise.all([
    resolver.resolve4("example.com", { ttl: true }),
    resolver.resolve4("myapp.example-cdn.net", { ttl: true }),
  ]);
  console.log(new Date().toISOString());
  console.log(
    "  apex:  ",
    apex.map((r) => `${r.address} (ttl ${r.ttl})`).join(", "),
  );
  console.log(
    "  target:",
    target.map((r) => `${r.address} (ttl ${r.ttl})`).join(", "),
  );
}

await snapshot();
setInterval(snapshot, 60_000);

Saved as watch.mjs and run with node watch.mjs, it prints the A records and remaining TTLs for both names every minute. You will often see the target change IPs more frequently than the apex, because the apex answer is cached at the flattening layer as well as at the public resolver.

The Trade-offs of CNAME Flattening

Flattening is invisible when things are working, which makes its costs easy to overlook. These are the ones that matter in practice.

1. CDN steering sees the wrong location

CDNs and global load balancers usually pick an edge IP based on where the DNS query came from. Without flattening, that is the visitor's recursive resolver, which is typically close to the visitor. With flattening, the query comes from your DNS provider's resolver instead.

Large anycast DNS providers have servers in many cities, so the flattening resolver is often near the visitor anyway. Some also send EDNS Client Subnet (ECS) data on the upstream query so the CDN can see a truncated version of the visitor's network. But neither is guaranteed. If your provider resolves from a handful of central locations without ECS, a visitor in Sydney may be handed an edge in Frankfurt. That is a direct cost to website speed.

Factor	Plain CNAME (subdomain)	Flattened CNAME (apex)
Who queries the CDN	Visitor's recursive resolver	Your DNS provider
Location the CDN sees	Near the visitor (usually)	Near the provider's server, or ECS approximation
TTL on the final A record	Set by the CDN	Set or capped by your DNS provider
Number of lookups for the visitor	Two or more	One
Visible CNAME chain	Yes	No
Standards-defined behaviour	Yes	Provider-specific

2. TTLs are stacked or rewritten

A flattened answer can be cached twice: once in your provider's flattening cache (usually for the target's TTL) and again by the visitor's resolver for whatever TTL the provider returns. If the CDN sets a 20-second TTL so it can shift traffic quickly, but your provider serves the flattened record with a 300-second TTL, the CDN loses most of its agility. Check what TTL your provider uses and whether you can change it. Our TTL guide explains why this matters during migrations.

3. Failure modes move to your DNS provider

With flattening, if the target's authoritative servers are slow or down, your DNS provider is the one waiting. Some providers serve the last known good answer; others return SERVFAIL or an empty answer for your apex. Either way, an outage at the target's DNS now shows up as a problem at your root domain's DNS.

4. DNSSEC requires online signing

If your zone is signed with DNSSEC, every flattened A and AAAA record needs a valid signature. Because the IPs change dynamically, the provider cannot pre-sign them. It has to sign answers on the fly with a key it holds online. Providers that support both flattening and DNSSEC do exactly this, but it rules out offline-key setups and some secondary arrangements. Also note that the target's own DNSSEC chain is not visible to the visitor: they validate your signature over the synthesised addresses, not the target's records. See What Is DNSSEC? for the general signing model.

5. Zone transfers do not carry the logic

Flattening is server behaviour, not data. If you transfer the zone to a secondary provider, the secondary receives either the CNAME (which it may refuse at the apex) or a snapshot of the A records, which will go stale. Running two providers with flattening at the apex usually means configuring the alias separately in each.

6. Debugging gets harder

Because the chain is hidden, a plain dig against a public resolver gives no clue that the apex depends on another hostname. Document your flattened records somewhere your team will find them.

Apex-Only vs Flatten Everything

Cloudflare and some other providers let you choose whether to flatten only the apex or every CNAME in the zone. Flattening subdomains is rarely necessary because subdomains can legally use CNAMEs. You might enable it for:

• Reducing lookups for clients behind slow resolvers, since one answer replaces a chain.
• Hiding internal or vendor hostnames from casual inspection.
• Working around clients that mishandle long CNAME chains.

For most sites, apex-only flattening is the right default, because it limits the CDN-location and TTL trade-offs to the one name where you have no alternative.

When Flattening Is the Right Choice

Use flattening (or an ALIAS built on it) when:

1. Your platform gives you a hostname, not stable IPs, and you want the bare domain to serve content directly.
2. Your DNS provider has a large anycast footprint or sends client subnet data, so CDN steering stays accurate.
3. You do not need the CDN's very short TTLs at the apex.

Prefer another approach when the platform publishes stable anycast IPs you can use in A records, or when you are happy to redirect the apex to www and keep the real CNAME on the subdomain.

---

CNAME Flattening FAQ

Conclusion

CNAME flattening is a simple idea with outsized impact: the authoritative server does the CNAME chase itself and returns plain addresses, which makes hostname-based hosting possible on a root domain without breaking the rules that keep SOA, NS and MX records working. For most sites on a well-distributed DNS provider, it just works.

The cost is that you are handing several decisions to your DNS provider: where the target lookup happens, how long the result is cached, how failures are handled, and how DNSSEC signatures are made. Before you depend on flattening for an important domain, find out how your provider handles each of those, compare the TTLs on your apex and target, and test from a few regions. That small amount of diligence turns flattening from a black box into a well-understood part of your setup.

Here are some useful references for going deeper on CNAME flattening:

1. Cloudflare Docs: CNAME flattening — how Cloudflare flattens apex and optional subdomain CNAMEs.
2. RFC 1034: Domain Names - Concepts and Facilities — defines CNAME behaviour and the no-other-data rule.
3. RFC 2181: Clarifications to the DNS Specification — clarifies CNAME restrictions and TTL handling.
4. RFC 7871: Client Subnet in DNS Queries — the EDNS Client Subnet option that helps preserve CDN steering accuracy.
5. Cloudflare Learning Center: What is a DNS CNAME record? — background on how CNAME records normally resolve.