DNS glossary

What is CNAME (canonical name)?

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.

CNAME (canonical name) is a DNS record type that maps an alias domain name to a canonical name, enabling multiple hostnames to reference a single target that automatically updates when the service address changes. Organizations commonly use CNAMEs to point hostnames at content delivery networks, hosted applications, and load balancers, reducing manual edits across large zones and simplifying service migrations. However, CNAMEs introduce operational risks including security vulnerabilities like subdomain takeover when pointing to external services, resolution delays with long alias chains, and compatibility issues when coexisting with other record types like MX or TXT records, requiring regular audits and careful management to prevent DNS failures and domain hijacking.

  • CNAME records cannot coexist with other record types at the same name per RFC 1034, which is why they are prohibited at zone apex where SOA and NS records must exist.
  • Dangling CNAME records pointing to deprovisioned external services create subdomain takeover vulnerabilities where attackers can claim the target domain and serve malicious content under the organization’s name.
  • Long CNAME chains add lookup latency and resolution complexity, while loops between aliases cause lookups to fail with SERVFAIL errors that resolvers cap to prevent infinite recursion.

CNAME at a glance

AttributeValue
Full nameCanonical name
CategoryDNS record type
Defined inRFC 1034 and RFC 1035
Protocol and portDNS, port 53 over UDP and TCP
OSI layerApplication layer (layer 7)
Primary usePointing one domain name at another so the alias inherits the target's records
Related termsA record, AAAA record, ALIAS record, DNS zone, TTL, Zone apex

How CNAME works

A CNAME record stores an alias name and the canonical name it points to. When a resolver queries the alias, the answer tells it to look up the canonical name instead.

  1. Client queries the alias: A client asks a recursive resolver for a record, such as an A record, for the alias name, for example www.example.com.
  2. Server returns the CNAME: The authoritative server finds no address data at the alias but finds a CNAME record there. It returns that record, which names the canonical name.
  3. Resolver restarts at the target: The resolver repeats the query for the canonical name, using the same record type. This may involve a different zone or a different authoritative server.
  4. Final answer is returned: The resolver receives the records for the canonical name, such as its A or AAAA addresses, and returns the full chain to the client, which uses the addresses.

A name that has a CNAME record must not have any other record types at the same name, which is why a CNAME cannot sit at a zone apex, where SOA and NS records must exist. Each link in the chain is cached according to its own TTL, and long chains add lookup time.

Why CNAME matters in enterprise networks

CNAME records let many names depend on one target. When a service changes its address, only the A or AAAA records at the canonical name need to be updated, and every alias follows automatically. This reduces manual edits across large zones and is widely used to point hostnames at content delivery networks, hosted applications and load balancers.

The same indirection creates operational risk. RFC 1034 requires that a name with a CNAME have no other data, so adding a CNAME where MX, TXT or NS records already exist can break mail delivery or domain verification. Long chains slow resolution and make troubleshooting harder, and a loop between two aliases causes lookups to fail.

There is a security implication as well. If a CNAME points to an external service whose resource has been deprovisioned, an attacker may be able to claim that target and serve content under the organization's domain, a condition known as a dangling record or subdomain takeover. Regular audits of CNAME targets, and removing aliases when the services behind them are retired, prevent this problem.

CNAME vs A record

An A record maps a name directly to an IPv4 address, while a CNAME maps a name to another name that must then be resolved. What is A record?

AttributeCNAMEA record
Points toAnother domain nameAn IPv4 address
Resolution stepsAt least one extra lookup at the canonical nameAnswer is returned directly
Coexistence with other records at the same nameNot allowed, per RFC 1034Allowed alongside MX, TXT and NS records
Use at the zone apexNot permitted, because the apex holds SOA and NS recordsPermitted
Effect of a target address changeAliases follow the target automaticallyEach A record must be edited separately

CNAME vs Alias record

A CNAME is a standard DNS record type defined in RFC 1034, while an alias record is a provider-specific feature that lets a name, often the zone apex, follow another name or resource without being a true CNAME.

AttributeCNAMEAlias record
StandardizationStandard record typeProvider-specific, not a standard record type
Allowed at the zone apexNoUsually yes, depending on the provider
Answer returned to the clientA CNAME record followed by the target's recordsTypically the final address records, resolved by the provider
Portability between DNS providersPortableBehavior varies and may not transfer

Common CNAME issues

Adding a CNAME at the apex of a zone conflicts with the SOA and NS records that must exist there. Servers may reject the zone load, or mail and delegation may break if the record is accepted.

A CNAME created at a name that already has MX, TXT or other data violates RFC 1034. Symptoms include mail delivery failures, lost verification records and inconsistent answers between resolvers.

Aliases that point to aliases add lookups and latency, and a loop between two names causes resolution to fail with SERVFAIL. Resolvers cap chain depth, so deep chains can fail intermittently.

A CNAME left pointing to a deleted or decommissioned target returns NXDOMAIN for the alias. If the target name belongs to an external service that someone else can claim, the alias can be abused for subdomain takeover.

The alias and the canonical name each carry their own TTL, so a change at the target may reach clients at different times. Engineers see some users hitting the old address after a cutover until both cached entries expire.

See how unified DDI simplifies network operations

Manage DNS, DHCP and IP addresses from one platform with automation, visibility and control built in.

CNAME FAQ

Related terms

Article

A record

An A record is a DNS record that maps domain names to IPv4 addresses.

Learn more
Article

AAAA record

An AAAA record is a DNS record that maps domain names to IPv6 addresses.

Learn more
Article

DNS record

A DNS record is a data entry that tells DNS servers how to respond to queries for a specific domain name.

Learn more
Article

Fully Qualified Domain Name (FQDN)

A Fully Qualified Domain Name (FQDN) is a domain name that specifies its exact location in the DNS tree hierarchy.

Learn more
Article

Time to Live (TTL)

TTL (time to live) is a setting for each DNS record that specifies how long a resolver caches the DNS query before it expires.

Learn more
Article

MX record

An MX record is a DNS record that provides the domain names of mail servers that receive emails on behalf of a domain.

Learn more
Article

TXT record

A TXT record is a DNS record that provides descriptive information in text format.

Learn more
Article

DNS zone

A DNS zone is a contiguous portion of the domain name space for which administrative responsibility and authority have been delegated to a single manager.

Learn more