Why a DNS zone apex cannot use a standard CNAME

A zone apex must contain SOA and NS records, which conflict with a standard CNAME. Use supported flattening, address records, or an HTTP redirect instead.

Guance Editorial Team 2026-10-27 3 min read Updated 2026-10-27

Best practices

Illustration of application modules working together

A DNS zone apex cannot contain a standard CNAME because it must already contain SOA and NS records. A CNAME owner cannot also contain those ordinary record types. For the example.com zone, that restriction applies at example.com.

Here, “apex” means the top of a particular authoritative zone, not only the global DNS root. A separately delegated subdomain has its own zone apex and the same constraint.

Understand the record conflict

A CNAME declares the owner name to be an alias of another name. Ordinary records such as A, AAAA, MX, TXT, SOA, and NS cannot coexist at that same owner. DNSSEC-related records have specific exceptions; those exceptions do not permit apex SOA and NS data to coexist with a CNAME.

The apex needs its SOA to describe zone authority and administrative data, and its NS records to identify the zone's authoritative servers. Replacing them with an alias would undermine the zone itself.

Authoritative software may reject the conflicting zone. If a service permits invalid data, resolver behavior and queries for mail, verification, or authority records can fail or become inconsistent. Do not rely on a particular resolver accepting the configuration.

Use a supported alternative

Provider-specific aliasing or flattening. Some DNS providers offer ALIAS, ANAME, or CNAME flattening. The provider resolves the target and serves suitable address answers without publishing an ordinary conflicting apex CNAME. Feature names, scope, caching, and restrictions differ across providers.

Cloudflare's flattening is one example. Its behavior depends on provider resolution and caching; it is not a promise to contact the target's authoritative servers afresh for every client query.

A and AAAA records. If the destination supplies supported, stable addresses, publish them directly at the apex. Maintain them when the service changes. Do not copy a current CDN edge address unless the provider explicitly supports that use.

An HTTP redirect. Point the apex at a service that returns a redirect to www.example.com. DNS itself does not return HTTP 301 or 308 responses. The redirect service needs a valid apex certificate for HTTPS requests, and the destination must recognize its own hostname.

What about ordinary subdomains?

A name such as app.example.com can use a CNAME when it has no conflicting data. If that name is itself a delegated zone apex, however, the SOA/NS constraint applies there too. The relevant test is the record role at the owner name, not simply whether the name contains three labels.

A control panel may let you enter an apex record labeled “CNAME” while implementing flattening internally. Inspect the provider documentation and actual authoritative answers to understand what is published.

Recover from a conflicting configuration

Replace an invalid apex CNAME with the appropriate supported alternative, then verify SOA, NS, A/AAAA, MX, and required TXT records. Check that MX targets have valid address records and are not aliases. Allow for cached data and test real mail and web requests; deleting one bad record does not guarantee immediate recovery everywhere.

HTTP synthetic tests can help observe reachability after the change, but authoritative DNS checks remain necessary to validate the record structure.