DNS Flattener

A CNAME (Canonical Name) recordis an alias: it says “this name is really just another name for that name.” When a resolver meets a CNAME it restarts resolution at the target, following the pointer until it reaches the real address records (RFC 1034 §3.6.2). A query for the CNAME type itself is not restarted, which is what lets a lookup tool read the alias directly rather than being bounced straight to the target.

The catch is the coexistence rule. RFC 1034 §3.6.2 states that “if a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.” RFC 2181 §10.1 hardens this into a precise rule: exactly one situation may hold at any name — a single CNAME (alongside its permitted DNSSEC records), one or more non-CNAME record sets, no records at all, or the name simply not existing. You cannot mix a CNAME with anything else. RFC 2181 §10.3 adds a related constraint that catches people out: the targets of NS and MX records must not themselves be aliases.

There is one modern exception. The DNSSEC extensions update the rule so that a CNAME may coexist with the signature and denial-of-existence records that secure it (RFC 4035 §2.5). That is a deliberate, narrow carve-out for cryptographic metadata — it does not open the door to putting ordinary records next to a CNAME. Chains of one CNAME pointing at another are permitted but, per RFC 2181, “should be avoided due to their lack of efficiency”; loops must be detected and handled (RFC 1034).

The zone apex is your bare root domain — example.com with nothing in front of it. Unlike a subdomain, the apex is required to carry certain records for the zone to work at all: an SOA record and a set of NS records always live there. That is exactly where a CNAME becomes impossible. Because the apex must also hold SOA and NS records, which the coexistence rule forbids alongside a CNAME, a literal CNAME at the apex is a protocol violation rather than a provider limitation.

This is why so many people hit the wall: they want example.com to point at a load balancer or CDN hostname the way a wwwsubdomain can, and the DNS provider either refuses the record outright or does something else behind the scenes. When a tool or provider allows a raw apex CNAME anyway, the symptoms are informal but recognizable — mail (MX) lookups failing at that name, resolvers behaving inconsistently, and third-party verification records that were supposed to sit at the apex getting shadowed by the alias. The clean fix is never “force the CNAME through”; it is one of the apex-aliasing techniques below.

CNAME flatteningsidesteps the apex problem by moving the work off the wire and into the authoritative nameserver. Per Cloudflare’s documentation, flattening resolves the CNAME chain at Cloudflare’s own infrastructure and “returns the final IP address instead of a CNAME record.” The answer that leaves the nameserver is a synthesized A or AAAA record, so no CNAME ever appears at the apex on the wire and the coexistence rule is never violated. On Cloudflare this is automatic at the apex on every plan; flattening non-apex records is plan-gated.

Because the address is synthesized, TTL handling changes. On Cloudflare, proxied records answer with Cloudflare’s anycast IPs at a TTL of 300 seconds, while DNS-only records use the lower of the target record’s TTL and the CNAME’s own configured TTL. One documented caveat is worth flagging: aggressive flattening can break third-party domain-verification flows that expect to see the literal CNAME target on the wire rather than a resolved address.

ALIAS, ANAME, and the standardization that never shipped

Other providers offer the same capability under different names. ALIAS and ANAMErecords (used by the likes of Route 53 and DNSimple) are provider-specific record types that do the same apex-aliasing job as flattening — they are non-standard, each implemented in the provider’s own resolver. There was an effort to standardize the idea: the IETF draft draft-ietf-dnsop-aname reached revision -04 in 2019 and then expired, never becoming an RFC. To this day there is no standardized DNS record type dedicated to apex aliasing.

HTTPS/SVCB (RFC 9460): the standards-track answer

The gap did eventually get a standards-track answer in the HTTPS and SVCB records of RFC 9460 (2023). Their AliasModeexists precisely for this: RFC 9460 §2.4.2 says its “primary purpose ... is to allow aliasing at the zone apex, where CNAME is not allowed,” and unlike a CNAME it does not affect other record types and applies to a specific service. It addresses the same problem the ANAME draft tried to solve, this time as a published standard. The remaining obstacle is client adoption: as of late-2025 testing, AliasMode was supported by Safari only, with Chrome and Firefox not yet implementing it. The protocol problem is solved; the browsers are still catching up. Flattening, ALIAS/ANAME, and eventually AliasMode are the three practical routes out of an apex CNAME.

This tool follows each CNAME chain to its terminal A/AAAA records and lays the result out as original → resolved record pairs, with a per-type count in the summary above the table. Reading it is a matter of comparing the two sides of each pair and scanning the counts for the patterns that matter.

Original vs. resolved pairs

The Original Recordcolumn shows what is actually published at the name — often a CNAME. The Resolved Record column shows where that pointer ultimately lands after the chain is followed, typically an A or AAAA address. When the two columns differ in type (a CNAME on the left, an A on the right), you are looking at an alias that was chased to its endpoint. When they match, the name already pointed straight at an address.

Per-type counts and chain length

The Record Typessummary tallies how many of each type were found, which is a fast way to sanity-check a domain’s shape at a glance. The signal to watch for is chain length: every unflattened CNAME hop is one more lookup a resolver must perform in sequence (absent caching), adding latency. RFC 2181 discourages long chains as inefficient — note it does not call them an error, so a chain is a smell, not a failure. Server-side flattening collapses those hops into a single synthesized answer.

What to act on

Two findings deserve action. First, a long chain — consider flattening it at the provider to cut the extra lookups. Second, and more urgently, a CNAME at the bare apex: that is the classic misconfiguration this tool is built to catch, and the fix is provider-side flattening, an ALIAS/ANAME record, or eventually an HTTPS AliasMode record — not forcing the raw CNAME. If a change is mid-rollout and the resolved address looks stale, our DNS propagation checker shows how far it has spread, and if you flatten with DNSSEC enabled, confirm the signed answer validates with our DNSSEC validator.