CNAME

A CNAME (canonical name) record is a DNS record that declares one domain name to be an alias of another name, called the canonical name. When a resolver finds a CNAME, it restarts the lookup at the target name and returns the records found there, together with the CNAME itself.

Among DNS records, the CNAME is unique because it points to a name, not to data. An A record maps a name to an IPv4 address and an MX record names a mail server, but a CNAME delegates the entire answer for its owner name to a different name, which may live in a different zone or belong to a different operator.

How CNAME resolution works

Suppose shop.example.com has a CNAME pointing to example.cdnprovider.net. A client asks its resolver for the A record of shop.example.com. The authoritative server for example.com returns the CNAME, and the resolver then queries the target name and finally receives the A record of the CDN host. The client gets the full chain in one response.

Each step in a chain can carry its own TTL, and resolvers cache each record separately. A chain of CNAMEs is permitted, but every extra hop adds a potential lookup and a point of failure. Resolvers stop after a limited number of hops, commonly around 8 to 16, to protect against loops.

The CNAME coexistence rule

The DNS specification states that a name with a CNAME record must not have any other record type, with exceptions only for DNSSEC records such as RRSIG and NSEC. The reason is logical: if a name is an alias, every question about it must be answered by the target, so other data at the same name would be contradictory.

This rule has a major practical consequence: a CNAME cannot be placed at the zone apex. The apex, such as example.com itself, must hold SOA and NS records, so it cannot also hold a CNAME. A common mistake is trying to point a bare domain at a hosting provider’s hostname this way, which either fails in the DNS editor or breaks mail and delegation.

CNAME compared with neighboring record types

Choosing between a CNAME and other record types depends on who controls the target address and whether the name is the apex. The table compares the CNAME with records that are often considered as alternatives.

ALIAS, ANAME or CNAME flattening are not standard record types on the wire. The authoritative provider resolves the target itself and returns synthesized A and AAAA records, which makes apex aliasing possible. The trade-off is that geolocation answers may reflect the provider’s location rather than the user’s.

When to use a CNAME

A CNAME is the right choice when another party manages the addresses behind a service and may change them at any time. Content delivery networks, website builders, email marketing platforms and cloud load balancers typically ask customers to create a CNAME so that their own infrastructure changes require no customer action.

• Use a CNAME for subdomains that point to third-party services.
• Use A and AAAA records for the apex and for hosts whose addresses you control.
• Use flattening or ALIAS when the apex must follow a provider hostname.
• Keep chains short, ideally one hop, to reduce latency and failure points.

Performance should also be weighed. Every CNAME that crosses into another operator’s zone can trigger an extra resolution when caches are cold, adding tens of milliseconds on a first visit. Moderate TTLs on both the alias and its target keep these lookups rare, while still allowing the provider to move traffic quickly during maintenance or failover. For security-sensitive names, it is also worth checking that the provider supports DNSSEC signing of its target zone, because validation covers each link of the chain separately.

Risks and common mistakes

The most serious risk is the dangling CNAME. When a service is decommissioned but the CNAME remains, an attacker may claim the same target name at the provider and take over the subdomain, serving content or stealing cookies under the victim’s domain. Regular audits that remove CNAMEs to retired services prevent this.

Other frequent problems include CNAME loops, trailing-dot mistakes in zone files that turn target.example.net into target.example.net.example.com, and unexpected cookie or tracking effects when a first-party subdomain is aliased to a third-party analytics host.

A plain-language summary

A CNAME is a forwarding note in the internet’s address book. Instead of saying where a website lives, it says: look up this other name instead.

This is handy when someone else runs the service and may move it. You point your name at theirs once, and when they change their addresses, your name follows automatically. The one place you cannot use it is the main domain itself.

An example from practice

A software company launches a help center on a hosted support platform. The vendor asks it to create a CNAME from help.example.com to example.support-vendor.net. The DNS administrator adds the record with a TTL of 3,600 seconds, and the help center appears under the company’s own domain within an hour.

Two years later, the company moves to a different support tool and cancels the old account but forgets to delete the CNAME. A quarterly DNS audit flags that the target now returns an error from the vendor, a classic sign of a dangling CNAME.

The administrator removes the record the same day. This closes a subdomain takeover risk before anyone can register the abandoned vendor name and publish content under the company’s domain.