CNAME at the apex: ALIAS vs ANAME vs CNAME flattening

A CNAME record cannot sit at a zone apex, the root of a domain like example.com rather than a subdomain. The apex is required to carry SOA and NS records, and the DNS spec says a name with a CNAME cannot have anything else at that same name. Every DNS provider invented its own workaround for this, and they are not the same thing under the hood even though they solve the same problem.

Why a real CNAME cannot go at the root

This is not a vendor limitation, it is the resolution algorithm itself. A resolver that finds a CNAME at a name is required to follow it and discard every other record at that name. An apex needs its SOA and NS records to function as a zone at all, so a literal CNAME there would break the zone. There is no provider setting that changes this, it holds for every authoritative DNS server that follows the standard.

Three names, one workaround, different implementations

ALIAS (used by DNSimple and similar providers), ANAME (DNS Made Easy, easyDNS), and CNAME flattening (Cloudflare's term) are three separate provider-specific names for roughly the same trick: the provider resolves the target hostname to its A/AAAA addresses on its own servers, then answers your apex queries with those synthesized addresses instead of a real CNAME. Resolvers never see an alias at all, they get an A or AAAA record, so the apex's SOA, NS, and MX records stay untouched.

None of this is a standardized DNS record type. An IETF draft proposed a real ANAME record in the mid-2010s and it was later abandoned. What exists today is provider-specific behavior with a shared name pattern, which matters because moving providers can mean re-learning how the new one handles the same conceptual feature.

What actually differs between providers

The practical consequence: an IP change behind a flattened apex does not propagate on a timeline you set directly. It propagates on whatever refresh or live-resolution schedule that specific provider uses internally. Two sites on two different providers, both using what looks like the same feature, can show very different lag before a backend IP change actually reaches every client.

The DNSSEC problem most guides skip

A synthesized answer is not a real, pre-signed record in the zone. A strict DNSSEC validator that expects a signed answer for the name it queried can see a synthesized A/AAAA response and treat it as suspicious, since it does not match what the zone's signed data actually says at that name.

Cloudflare avoids this specific failure by signing the flattened answer live, at the edge, at the moment it serves the response, rather than trying to pre-sign a static synthesized record. Providers using a precomputed-and-refreshed model (the ALIAS/ANAME approach) have to solve this differently, typically by adding the resolved addresses into the zone and signing them through the normal signing process on their refresh cycle. Either approach can work, but they are not interchangeable, and testing DNSSEC validation specifically after switching providers or switching from a flattened apex to a different mechanism is worth doing rather than assuming compatibility carries over.

RFC 9460: a standards-based alternative most guides do not mention

RFC 9460 defines the SVCB and HTTPS record types, a real, published IETF standard rather than a provider workaround. These records let a zone directly publish service-binding information, including endpoint hints, HTTP/3 support signaling, and Encrypted Client Hello parameters, without needing a synthesized A/AAAA answer at all for that purpose.

The DNSSEC advantage is structural: HTTPS and SVCB records are static, real records in the zone, not values computed live or on a refresh cycle. That means they sign through the normal DNSSEC process the same way any other record does, no live-signing trick and no refresh-cycle re-signing needed. This does not fully replace ALIAS/ANAME/flattening for every use case, an apex still often needs an actual address record for plain HTTP or non-browser clients, but for the specific case of signaling how to reach a service over HTTPS, it is a standards-compliant option that avoids the synthesized-answer problem entirely. Worth knowing about even if a flattened apex is still the practical choice today. RFC 9460 has the full specification.

What to check before relying on any of these

• TTL propagation speed: ask the specific provider how fast a target IP change reaches clients through their flattened/ALIAS/ANAME implementation, do not assume it matches the target's own TTL
• DNSSEC compatibility: test validation specifically after switching providers or mechanisms, do not assume it carries over from a previous setup
• What a strict resolver sees: a synthesized answer is real from the client's point of view, but confirm the specific provider's signing approach if DNSSEC is enforced downstream
• Whether SVCB/HTTPS records fit the use case: a standards-based option worth evaluating alongside the provider workaround, not a guaranteed drop-in replacement

A quick way to check: query with DNSSEC requested and look at the response flags.

dig +dnssec yourapex.com A

An ad (authenticated data) flag in the response header means the answer validated. A validating resolver returning SERVFAIL instead means the synthesized answer failed validation under the new provider’s signing approach.

WebPixie's DNS monitoring checks the apex's actual records daily, including CNAME, A/AAAA, the DNSSEC chain (DNSKEY, DS, RRSIG, NSEC), and HTTPS/SVCB among its 20+ monitored record types, surfacing the old and new value whenever something at the apex changes. It cannot tell a provider how fast to propagate a flattened answer, but it does catch the resulting record change and a broken DNSSEC chain either way, regardless of which mechanism produced it.