DNS Flattener

A CNAME (Canonical Name) record is 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 www subdomain 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 flattening sidesteps 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 ANAME records (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 AliasMode exists 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 resolves the name you type for itself and follows its CNAME chain hop by hop to the terminal A and AAAA records. The name you asked about card names each hop in order, the addresses the chain ends at and the chain length; the table below it lays the same data out as original → resolved record pairs, with a per-type count in the summary.

When there is nothing to flatten

An empty table is never the answer on its own. If the name does not exist you are told so (NXDOMAIN); if it exists but publishes no address you are told that instead, along with the note that TXT and SOA records are outside this tool’s scope, so their absence here is not evidence they are not published. A chain that ends at a name with no address is reported as a broken alias, naming the hop it broke at, and a chain that returns to a name it has already visited is reported as a CNAME loop. A chain is followed to a maximum of 16 hops. If the resolver itself does not answer, that is said plainly too — it is not the same finding as a name that is absent.

Original vs. resolved pairs

The Original Record column 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 Types summary tallies how many of each type were found, which is a fast way to sanity-check a domain’s shape at a glance. The types it counts are the ones this tool resolves — A, AAAA, CNAME, NS and MX. Nothing else appears in the table: a TXT, SOA or CAA record has no alias chain to follow, so there is nothing for a flattener to do with it, and an empty row for it would only be noise. An absence here is therefore not evidence that a record is not published. 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.

Records are shown at the name that publishes them

RFC 1034 §3.6.2 is explicit that “if a CNAME RR is present at a node, no other data should be present,” so a name that is an alias is never shown here carrying NS, MX or address records of its own — those belong to whichever name actually publishes them, and that is where they appear. A lookup tool that asks a recursive resolver for the A records of an alias gets the target’s addresses back and can easily attribute them to the alias; this tool queries each owner name explicitly and checks that every answer really was published there.

What else we check at a zone apex

When the name you type is a zone apex — it carries NS records — you also get the zone overview: the apex’s own addresses, its nameservers and its mail exchangers, each target resolved to its addresses. On top of that we try a fixed list of 34 common subdomain labels under it (www, mail, api, blog and the like) and list the ones that resolve to an address, each resolved by the same chain logic as the name you asked about. That is a guess-and-check of common names from a hardcoded list, not a reading of the zone: it is not exhaustive, and a name missing from it is not evidence that the name does not exist. Those results are shown separately from the name you asked about, and the full label list is on the results page. For subdomain discovery that is actually evidence-based, our subdomain lookup reads Certificate Transparency logs instead.

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 when one is observed at an apex the results say so explicitly, citing RFC 1034 §3.6.2 and RFC 2181 §10.1. 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.