The CNAME Record

A CNAME replaces the whole node

A CNAME record makes one name an alias for another. When a resolver asks about the alias, it is told the name it asked for is not the real name, and it is handed a second name to look up instead.

Three terms sit inside that sentence. The owner name is the name being aliased, such as www.example.com. The canonical name is the target in the record's data. The record itself is the CNAME. RFC 8499 notes that calling the owner name a CNAME is unfortunate, since the owner is precisely not a canonical name; the usage is universal anyway, and this guide follows it.

The rule that matters is what the alias does to the rest of the node. RFC 2181 states it as four alternatives, exactly one of which is true for any name: one CNAME exists, with a narrow exception for the signature records DNSSEC adds; one or more records exist and none is a CNAME; the name exists but owns no records; or the name does not exist. There is no fifth case where a CNAME sits alongside an address or TXT record.

A CNAME does not redirect a hostname. It replaces the node, and everything below is that sentence in disguise.

Why the apex will not take one

The bare domain cannot be a CNAME. The reason is not a special rule about the apex, which is where most explanations go wrong.

The apex is the top point of a zone, example.com with nothing in front of it. RFC 8499 defines it as the point in the tree owning an SOA record and the corresponding authoritative NS set, and those two records are what make the zone a zone. Apply the exclusivity rule to that. A CNAME at the apex would have to be the only record there, displacing the SOA and the NS set, and the zone would stop being a zone. Nobody wrote a prohibition on apex CNAMEs; it falls out of two definitions colliding.

The derivation is worth knowing because the same collision happens far below the apex. A subdomain that is a CNAME cannot also hold the TXT record a service asks you to publish for verification, or its own SPF record. The request looks reasonable and the zone refuses.

The refusal usually arrives as an editing error rather than a broken lookup, which confuses the diagnosis. RFC 1912 observes that name server software sees the CNAME and declines to add any other resource for that name. Anyone told the platform is buggy is generally looking at the standard working correctly.

The workarounds providers invented for the apex

ALIAS records, ANAME records and CNAME flattening are three names for one trick, and the trick is not a new record type. The provider accepts an alias-shaped entry in its control panel, resolves the target itself, and publishes an ordinary A or AAAA record on the wire. The client never sees an alias, so nothing in the protocol is violated.

The vendor documentation says as much. One provider calls its ALIAS record a dynamic A record that looks up addresses on the fly. Another states plainly that its alias record is a provider-specific extension to DNS, that you can create one at the apex where you cannot create a CNAME, and that a lookup returns an A or AAAA record.

Two consequences follow. The feature belongs to your DNS host rather than to your domain, so a zone that depends on it does not move cleanly to a provider that lacks it. And because the provider resolved the target for you, the answer reflects the provider's view of it rather than yours. ANAME is not a record type that exists: it was an Internet-Draft that expired without becoming a standard, and it has no formal standing in the IETF process.

A standardized answer does exist. RFC 9460 defines the SVCB and HTTPS record types and says the primary purpose of its AliasMode is to allow aliasing at the zone apex, where CNAME is not allowed. That is an actual record type rather than a control-panel convenience. Support is uneven, so check whether your host can publish one.

What a chain of aliases costs

An alias whose target is itself an alias is legal and common. RFC 1034 instructs software to follow CNAME chains rather than fail on them, and to signal a loop as an error. The cost is in how that following happens.

The server algorithm copies the CNAME into the answer, replaces the query name with the canonical name, and starts again. A server that also holds the target can finish inside one response. When the target lives in someone else's zone, the answer contains the alias and nothing more, and the resolver has to begin a fresh lookup for a name it has just learned. A platform hostname pointing at a load balancer pointing at a CDN hostname is three resolutions before anyone has an address.

Each link caches under its own TTL, so the link that expires first sends a resolver back for a new answer and a short TTL anywhere sets the pace for the whole path. That is why flattening is sold on speed as much as on the apex, since collapsing the chain to an address removes the round trips.

Nothing in the standards caps chain length. Resolver implementations impose their own limits, and those differ by implementation and version, which is why a chain that resolves from one network can fail from another. Treat any number you are quoted as that implementation's, not a rule.

MX and NS must point at a real name

This restriction is separate from the exclusivity rule and is missed more often. RFC 2181 says the name used as the value of an NS record, or as part of the value of an MX record, must not be an alias, and must have one or more address records. The restriction is on the target field, not the owner.

The failure is quiet. RFC 2181 notes that when an alias is used in that position, no address is returned alongside the NS or MX value. Delivery then depends on the receiving system making a second lookup it may or may not make, so the same configuration works for some senders and not others. Intermittent mail with no error in your own logs is the classic presentation. RFC 1912 adds that NS records aimed at a CNAME conflict badly with server software.

The practical form is short. Mail exchangers and nameservers are named by hostnames that own address records directly. If the hostname your provider gave you for either purpose is an alias, ask for the address-record name instead, and cite RFC 2181 if it is disputed.

The same restriction explains why service discovery needed a record type of its own. An alias replaces the whole node, so a name like _submission._tcp.example.com cannot be a CNAME pointing at a provider and still carry the port number and the preference values a client needs. SRV records exist for exactly that gap. RFC 6186 uses them so a mail client can be given an address and work out the submission and access servers from the name alone, instead of asking the user for hostnames and port numbers. The distinction is worth holding onto when a provider’s setup page mixes both in one table: the CNAME rows are aliases for names you will type into a browser, and the SRV rows carry the target, port, priority and weight that software reads without anyone seeing them.

Choosing between a CNAME and an A record

The usual advice is to prefer a CNAME for anything that is not the apex, so a platform can change its addresses without involving you. It is right often enough to be dangerous, because it skips the questions that decide the case.

• Who controls the address. If the destination belongs to a platform that reserves the right to move it, an alias is correct, because their changes reach you without an edit.
• Whether the name needs anything else. If the same hostname must carry a verification TXT record, an SPF record, a CAA policy or its own MX, the alias is ruled out before the argument starts.
• Whether it is the apex. The bare domain takes an address record or a provider alias feature, never a CNAME.
• Whether the name is a mail exchanger or a nameserver. Those take address records.
• How much resolution you want to pay for. An alias adds a lookup, and an alias into someone else's chain adds several. On a hostname fetched once per session that is invisible. In the critical path of a page load it is not.

Summarized: a CNAME buys somebody else's operational freedom and costs you the rest of the node. Where that trade is good, take it. Where you own the address and the name has to carry other records, an address record is the simpler object.

A forgotten CNAME is a claimable subdomain

The most damaging CNAME in most zones is one nobody remembers creating. A campaign site or a trial account goes up on a hosted platform, a subdomain is aliased to the platform hostname, the project ends, the account is closed, and the record stays.

The alias now points at a name the platform no longer assigns to you. OWASP treats this as the most common route to subdomain takeover, and it outranks the equivalent problem with address records because of what it costs an attacker. Reclaiming a released IP address means waiting for one address to come out of a provider pool. Reclaiming a released platform hostname usually means signing up and typing the name into a form.

What that buys is a host inside your namespace. OWASP's list of consequences covers session cookies scoped to the parent domain, Content Security Policy rules that trust your subdomains, phishing on a name your customers recognize, and valid TLS certificates for the subdomain, since certificate validation asks DNS and DNS answers in the attacker's favor. Where MX records are involved, mail follows.

The fix is an order of operations that costs nothing. Serve a redirect or a maintenance page, remove or repoint the record, wait for cached answers to expire, and only then close the platform account. The other order opens a window that stays open until somebody finds it.

For a zone you have inherited, export it rather than reading a control panel screen by screen, and resolve every CNAME target. One that returns no answer, or a platform's generic not-found page, is a record to remove today rather than add to a list.