Zone Apex

The DNS zone apex is the top node of a zone. It is the name where that zone’s own records begin, and the name that must carry the zone’s SOA and NS records. In the ordinary case it is the registered domain itself: example.com, not www.example.com. That is why it is also called the apex domain, the naked domain or the root domain. It is not a record type and not a CDN feature. It is not simply a name with no subdomain, either: a subdomain delegated as its own zone is the apex of that zone. So blog.example.com can be a zone apex too. One consequence dominates the term in practice. A CNAME may not coexist with other data. The apex must hold SOA and NS. So the apex cannot be a CNAME. Yet pointing a CNAME at the provider’s edge hostname is exactly how a CDN is normally attached.

How it works

A zone is anchored at its top node. RFC 1034 describes the records there as being “of two types: name server RRs that list, one per RR, all of the servers for the zone, and a single SOA RR that describes zone management parameters” (RFC 1034 section 4.2.1). Those two record sets are what make a name an apex. Every other name in the zone hangs below it.

The second rule is CNAME exclusivity. RFC 1034 phrases it as advice: “If a CNAME RR is present at a node, no other data should be present” (RFC 1034 section 3.6.2). RFC 2181 removes the wiggle room. It states that for any name in the DNS, exactly one of these is true: “one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs”; “one or more records exist, none being CNAME records”; the name exists but has no records; or the name does not exist (RFC 2181 section 10.1). The only companions a CNAME may have are DNSSEC signature and key records. RFC 1912 states the rule flatly: “A CNAME record is not allowed to coexist with any other data”. It walks through the apex case. If you put NS records and a CNAME on the same name, then “DNS servers like BIND will see the CNAME and refuse to add any other resources for that name”. So the delegation records are ignored, and with them every host in the zone (RFC 1912 section 2.4). A CNAME at an apex does not just fail for that one name. It can take the zone down with it.

That collides with CDN onboarding. CloudFront, for instance, gives each distribution a hostname “such as d111111abcdef8.cloudfront.net”. It expects you to “create a CNAME record in your DNS configuration to route DNS queries for the domain name to your CloudFront distribution”. Yet “you can’t create a CNAME record for the top node of a DNS namespace, also known as the zone apex; the DNS protocol doesn’t allow it” (AWS CloudFront documentation). Subdomains take that CNAME directly. The apex needs one of four mechanisms.

• ALIAS or ANAME record. A provider-specific record that looks like a CNAME in the editor but is resolved by the authoritative server. DNSimple’s name servers “perform a dynamic, real-time lookup of the hostname specified in the Content field” and “return the resulting A (IPv4) or AAAA (IPv6) records to the resolver”. So the client sees ordinary address records, never a CNAME (DNSimple ALIAS reference). easyDNS names its equivalent an ANAME, “which is like a CNAME for your zone apex”. ANAME records “get flattened into A records” (easyDNS).
• CNAME flattening. The CNAME stays in the zone. The provider follows it before answering: “Cloudflare finds the IP address that a CNAME points to” and “then returns the final IP address instead of a CNAME record” (Cloudflare CNAME flattening).
• HTTPS and SVCB aliasing. This is the standardised route, and the newest. RFC 9460 defines SVCB and HTTPS records that “enable aliasing of apex domains, which is not possible with CNAME”. The purpose of their AliasMode is “to allow aliasing at the zone apex, where CNAME is not allowed”. The RFC adds: “Unlike CNAME, AliasMode records do not affect the resolution of other RR types and apply only to a specific service, not an entire domain name.” (RFC 9460 section 2.4.2). It is an addition rather than a replacement. Because “legacy clients will not know to use this record”, operators “will likely need to retain fallback AAAA and A records alongside this SVCB record”.
• A and AAAA records to anycast addresses. There is no indirection at all. The apex publishes the CDN’s own addresses. This works because those addresses are anycast. A single published address is therefore answered by many locations rather than one machine.

Why it matters for a CDN

The apex is usually the name you most want on the CDN. It is what people type, what gets printed, and what inbound links and mail configuration are built around. It is also the one name in the zone where the CDN’s standard onboarding instruction, point a CNAME at our edge hostname, is not allowed. Every other hostname in a CDN setup is a subdomain, so it is easy. The apex needs a DNS provider that offers alias behaviour, flattening or HTTPS records, or it needs fixed addresses and the maintenance that implies. That single asymmetry is why the naked domain has a reputation as the awkward part of a CDN migration. It is also why choosing DNS hosting is a CDN decision rather than a registrar detail.

What CDNs do

The apex record is published by your DNS provider, so what is possible depends on that provider rather than on the CDN. Current behaviour differs across three common combinations:

• Cloudflare. You create an A, AAAA or CNAME record with the record Name set to @. You do not have to enable flattening for this case: “CNAME flattening occurs by default for all plans when your domain uses a CNAME record for its zone apex” (Cloudflare setup). Flattening every CNAME in the zone, by contrast, is a paid-plan option. If you are migrating in, you recreate the old provider’s ANAME or ALIAS yourself as a CNAME record. Flattening then resolves it (Cloudflare zone apex record).
• AWS Route 53 with CloudFront. An alias record is permitted at the apex where a CNAME is not. Route 53 answers an alias pointing at a CloudFront distribution with “one or more IP addresses for CloudFront edge servers that can serve your content”. An alias must have the same type as its target, and “creating a CNAME record for the zone apex isn’t supported even for an alias record”. Dual-stack therefore needs two alias records, one A and one AAAA. Route 53 does not charge for alias queries to AWS resources (Route 53 alias records).
• DNSimple. DNSimple uses a proprietary ALIAS record. It is “not defined by any standard RFC”, and it is resolved afresh on every query. Unlike a CNAME, it is able to “coexist with other record types (e.g., MX, TXT, NS records) on the same hostname” (DNSimple ALIAS reference).

Watch out for

• The exclusivity rule attaches to the name, not to the apex. Any name holding a CNAME can hold nothing else except DNSSEC records. So a bare CNAME on a name that also needs MX or a TXT ownership record breaks mail and verification. At the apex, SOA and NS are mandatory. So a CNAME there breaks the zone.
• ALIAS and ANAME are not in any RFC. They are named inconsistently: alias at Route 53, ALIAS at DNSimple, ANAME at easyDNS. Confirm what the destination provider offers before moving DNS. Expect to re-enter the record by hand rather than have it imported.
• An aliased or flattened target with no addresses of its own fails silently. Cloudflare warns: “If the final CNAME target has no A/AAAA records (a dangling CNAME), CNAME flattening returns an empty response (NODATA).” That reads like slow propagation rather than a broken target.
• Flattening hides the CNAME from resolvers. So a third-party service that proves ownership by reading your CNAME target can start failing once that record is flattened.
• Publishing A and AAAA at the apex pins it to those addresses. Anycast covers the loss of a location, not a renumbering. If the CDN retires or changes the addresses it gave you, nothing but your own DNS edit will follow. Alias records, flattening and HTTPS records keep the indirection and track the target themselves.
• An HTTPS record does not retire the apex A and AAAA records. RFC 9460 expects fallback address records for clients that do not query it. The HTTPS record applies only to queries for that record type. On Cloudflare, HTTPS records are synthesised automatically for proxied names. A manually added HTTPS record on a proxied name is not served (Cloudflare DNS record types).
• Apex is relative to the zone. So on a delegated subdomain zone, the same restriction applies at that subdomain. Being “a subdomain” of the registered name does not make it CNAME-able.
• Providers commonly expose the apex as @. Entering the record under www instead quietly creates a subdomain. The apex then keeps pointing wherever it did before.

Best practice

• Choose DNS hosting that offers alias behaviour or CNAME flattening at the apex. Keep the indirection. A name that resolves through the CDN’s own hostname survives the CDN changing addresses. A hand-entered A record does not.
• If you must publish addresses, use the CDN’s anycast addresses. Publish both A and AAAA. With anycast, “an entire data center can be taken offline and traffic will automatically flow to a proximal data center”, with no DNS change (Cloudflare on anycast).
• Publish HTTPS records at the apex where the provider supports them. Keep A and AAAA alongside for clients that do not query them.
• Never put a CNAME on a name that must also carry SOA, NS, MX or verification TXT records.
• Keep a www hostname CNAMEd to the same edge. Keep a redirect between the two. Then a failed apex mechanism still has a working path to the CDN.
• Verify from outside after every change. Query the apex for A, AAAA and HTTPS. Confirm the answers are the CDN’s and not your origin’s. Confirm the alias target itself resolves.