DNS Helper

CNAME

A CNAME record doesn't point at an address, it points at another name instead. Whatever that other name eventually resolves to, an A record, an AAAA record, even another CNAME, is the answer a visitor gets for the CNAME's own name too. Think of it as "this name is really just another name for that one."

The one hard rule: never on the apex

A CNAME can't be used on a domain's own apex, the root of the domain itself, the one covered on the Zone file & SOA page. A name with a CNAME record can't have any other ordinary record sitting at that same name, no A record, no MX, nothing else (DNSSEC's own signature records are the one exception), because a CNAME says "look entirely somewhere else" for every record type, and the apex always needs its own NS record and SOA record alongside whatever else is there. Those two can't be looked up somewhere else, so a CNAME and an apex are fundamentally incompatible.

If you want the apex itself to behave the way a CNAME does elsewhere, point at another name and follow whatever that name resolves to, that needs an ALIAS or ANAME style feature instead, a provider-specific workaround rather than a standard record type, covered on its own page.

Chains: a CNAME can point at another CNAME

A resolver will follow more than one hop if it has to. A CNAME pointing at a CNAME pointing at an A record still resolves, a visitor just gets whatever the chain ends on. Each extra hop can mean an extra lookup though, so a longer chain can add latency compared with a short one, and most providers' own setup instructions are written assuming a single hop. Where there's a choice, point a CNAME straight at its actual target rather than at another CNAME along the way.

Why use a CNAME instead of just copying the address?

The point of a CNAME is not having to know, or keep up with, the address behind it. A hosted service, a CDN, an email platform, often changes its own underlying addresses without warning, since it manages many customers' names behind shared infrastructure. Point a CNAME at their name instead of copying today's address into an A record, and it keeps resolving correctly even after their address changes, since it's looked up fresh every time rather than copied once and left to go stale.

A proxying CDN can hide a validation CNAME

Cloudflare can answer a CNAME lookup with its own address instead of passing the real target through, when the record is set to "Proxied" (the orange cloud) rather than "DNS only" (grey). That's the whole point of the feature for ordinary web traffic: Cloudflare sits in front, protects the origin, and nobody outside needs to know the real address. It becomes a problem the moment something outside Cloudflare needs to see the actual CNAME target through a plain DNS lookup, which is exactly what most domain ownership checks and DNS-01 certificate validation do. A certificate authority or a hosting platform checking a validation CNAME sees Cloudflare's own address instead of the value it expects, and validation fails, often with a vague error rather than a clear "this record is proxied" message. The toggle defaults to Proxied the moment a domain is first added through Cloudflare's dashboard, which is why this catches people who never consciously chose it.

Two exceptions worth knowing before assuming this affects every certificate check. It specifically breaks DNS-based validation, a lookup that needs the real CNAME target back. HTTP-01 validation, the default for a lot of origin-issued certificates, usually passes straight through a proxied record instead: Cloudflare forwards the actual HTTP request on to the origin, and the origin's own response is what gets checked, the CNAME being proxied never enters into it. HTTP-01 can still fail behind Cloudflare, but for a different reason, a WAF rule, Bot Fight Mode or Under Attack Mode intercepting the challenge request at the edge before it reaches the origin, not the mechanism described above. And Cloudflare's own free edge certificate, covering the connection between a visitor and Cloudflare itself rather than Cloudflare and the origin, doesn't run into this at all, proxied is the state it expects and needs, not something working against it.

The quick fix, switching the record to DNS only until validation passes and switching it back afterwards, works but has to be repeated every time a certificate renews or a platform re-checks ownership. The sturdier fix is to leave whichever record actually needs Cloudflare's protection proxied, and add a second, dedicated CNAME purely for validation, on its own name, permanently set to DNS only. Many services that require this already hand you a name built for exactly that purpose, worth checking for one before inventing your own layout.

Only A, AAAA and CNAME records can be proxied at all, TXT, MX and the rest are always DNS only regardless of the toggle, so this specific trap is limited to those three record types.

Cloudflare is the service most people run into this with, since it's the largest and the toggle is easy to trip over by accident, but the underlying behaviour isn't unique to it. Any DNS-level reverse proxy answers a lookup the same way by design, Sucuri's website firewall is another example. A CDN connected by pointing a CNAME straight at its own hostname, rather than through a separate on/off toggle, has the identical effect from the moment that CNAME exists. There's nothing to accidentally switch on or off there, proxying is simply the only mode a CNAME to that kind of service has.