A CNAME record lets one DNS name act as an alias for another name. It is useful when several hostnames should follow a service whose destination may change, but it has strict rules that distinguish it from an A or AAAA record. Misusing those rules can break a website, mail delivery, domain verification, or an entire DNS name.
This guide explains how CNAME resolution works, where aliases fit well, why they normally cannot be used at a zone apex, and how to test a configuration before relying on it in production.
What is a CNAME record?
CNAME means Canonical Name. The record identifies its owner name as an alias and points that alias to a canonical target name. For example, an administrator might make www.example.com an alias of web.example.net. The target is a hostname, not an IP address.
When a resolver asks for an address for the alias, it receives the CNAME relationship and continues resolution at the target name. The target may then provide an A record, an AAAA record, another CNAME, or other data relevant to the original query. The alias does not copy the target’s records into the source zone; it tells the resolver where to continue.
If the overall lookup process is unfamiliar, Domain Name System Explained describes how clients, recursive resolvers, and authoritative servers work together.
CNAME compared with A and AAAA records
An A record maps a name directly to an IPv4 address, while an AAAA record maps it to an IPv6 address. A CNAME maps one name to another name. The distinction determines who controls the final address.
- Use A or AAAA when you control the destination address and want the name to resolve directly.
- Use CNAME when the destination is identified by a hostname and the operator of that hostname may change its addresses.
The existing article DNS A Record Explained covers direct IPv4 mapping in more detail. For a wider comparison of common record types, see the ClouDNS guide to DNS records. This contextual external reference appears in the first half of the article.
How CNAME resolution works
Assume the DNS zone contains this conceptual relationship:
www.example.com. CNAME web.example.net.A client requesting the A record for www.example.com typically follows these steps:
- The client sends a query to its recursive resolver.
- The resolver finds that
www.example.comis an alias. - It continues the lookup for
web.example.net. - The authoritative data for the target returns an address or another answer.
- The resolver returns the CNAME path and relevant final data to the client, subject to caching and response-size limits.
The alias and target can be in the same DNS zone or in completely different zones. Each zone remains responsible for its own records, availability, TTL values, and DNSSEC signatures.
Good uses for a CNAME
A www hostname
A common design makes www an alias of a web platform or another hostname managed by the same organization. This lets the target’s address change without editing the alias record each time.
Third-party platforms
Cloud applications, content delivery platforms, hosted storefronts, help desks, and software-as-a-service products often provide a target hostname. A customer connects a subdomain such as shop, help, or status through a CNAME while the provider manages the final infrastructure addresses.
Service migration
An alias can separate the public hostname from an internal service name. During a planned migration, administrators can change the canonical destination while applications continue using the familiar alias. Caching still matters, so the change is not necessarily immediate.
The most important rule: no other data at the alias name
A DNS name that owns a CNAME record generally cannot own other record data. In practical terms, do not place A, AAAA, MX, TXT, or unrelated records at the same label as a CNAME. DNSSEC-related records required to secure the CNAME are a protocol-specific exception.
This exclusivity prevents contradictory answers. A name cannot simultaneously say “continue at this canonical name” and independently publish address, mail, or verification data. Many control panels reject the conflict; inconsistent servers or cached data may otherwise produce unreliable results.
Why a traditional CNAME does not fit at the zone apex
The zone apex is the bare domain, such as example.com. It must contain the zone’s SOA and NS records and often has MX, TXT, and other records. Because a CNAME cannot coexist with that required data, a standard CNAME cannot replace the apex.
Some DNS providers offer records called ALIAS, ANAME, flattened CNAME, or similar names. These are provider-specific features rather than ordinary CNAME records. The authoritative service follows the target and synthesizes compatible address answers at the apex. Behavior, TTL handling, DNSSEC support, IPv6 handling, and failure modes differ, so check the provider’s exact documentation before using one.
CNAME and email configuration
An MX record names the mail server responsible for a domain. Its target should resolve directly through address records rather than depend on a CNAME alias. Use a dedicated hostname with A and, when applicable, AAAA records for the mail exchanger.
Do not place a CNAME at a label that also needs MX or TXT data. This is especially relevant when the same name must publish SPF, DKIM, DMARC, verification, or other email-related information. The article DNS MX Record Explained describes the mail-routing role separately.
A CNAME is not an HTTP redirect
DNS aliasing happens before a browser makes an HTTP request. A CNAME does not change the address displayed in the browser, redirect one URL path to another, or automatically configure the destination web server for the alias hostname.
The target service must still recognize the requested hostname and present an appropriate TLS certificate. If the server is not configured for the alias, visitors may see a certificate error, a platform error, or the wrong site even though DNS resolution succeeds.
TTL and caching behavior
The CNAME record has its own TTL, and the final A or AAAA record has another. Resolvers may cache each part of the chain independently. Changing the alias target does not purge records already cached under the previous TTL.
Before a planned migration, reduce the relevant TTL early enough for older cached data to expire. After the move is stable, raise the TTL again to reduce unnecessary queries. Remember that the target operator controls the TTL of the final address records.
Avoid long chains and loops
A target may itself be a CNAME, forming a chain. Short chains can work, but every additional dependency may require another lookup and introduces another place where configuration or availability can fail. Long chains also increase the chance that a resolver reaches an implementation limit.
A loop occurs when aliases eventually point back to a name already visited—for example, one name points to a second and the second points to the first. No final answer exists, so resolution fails. Review the complete path whenever changing an alias.
Security risk: dangling aliases
A dangling CNAME remains in DNS after the referenced cloud, hosting, or software-as-a-service resource has been removed. If another party can claim that abandoned target, they may be able to serve content under the organization’s subdomain. This is commonly called subdomain takeover.
Maintain an inventory of third-party aliases, identify an owner for every integration, and remove DNS records promptly when a service is retired. Before deleting the external resource, determine whether the provider requires the DNS mapping to be removed first. Monitor important aliases for unexpected target or response changes.
DNSSEC and CNAME records
DNSSEC can authenticate the CNAME data in a signed source zone. Resolution may then cross into another zone with its own signing status. A validating resolver evaluates each applicable chain of trust; signing the alias zone does not automatically sign or control the target zone.
DNSSEC confirms that signed DNS data has not been altered in transit. It does not prove that the chosen canonical target is operational, correctly configured for the website, or still owned by the intended provider.
How to configure a CNAME safely
- Choose the alias label. Use a subdomain that does not need other DNS record types.
- Confirm the exact target. Copy the hostname supplied by the service and never enter an IP address as CNAME data.
- Check name formatting. In raw zone files, a trailing dot marks a fully qualified target. Control panels often add it automatically, but behavior varies.
- Review existing records. Remove or migrate conflicting A, AAAA, MX, TXT, or other data at the alias owner.
- Select a sensible TTL. Use a shorter value during a controlled migration and a stable value afterward.
- Configure the destination service. Add the alias hostname to the web platform and provision a valid TLS certificate.
- Test from multiple resolvers. Confirm both the CNAME relationship and the final address response.
- Document ownership. Record who owns the DNS entry and the external resource so it is removed safely during decommissioning.
How to test and troubleshoot
Query the alias explicitly and then query the final record type:
dig CNAME www.example.com
dig A www.example.com
dig AAAA www.example.comCheck the authoritative servers when recursive caches may contain old data. Follow the complete target chain and compare TTL values. If DNS works but the website does not, test TLS certificate coverage, virtual-host configuration, HTTP responses, and the third-party platform’s domain-verification status.
The protocol rule that a CNAME owner must not contain other data, along with requirements for MX and NS targets, is clarified in RFC 2181: Clarifications to the DNS Specification.
Common mistakes checklist
- Entering an IP address instead of a hostname as the CNAME target.
- Adding a CNAME where A, AAAA, MX, TXT, or other records already exist.
- Trying to use a standard CNAME at the zone apex.
- Assuming DNS aliasing performs an HTTP redirect.
- Creating a long chain or an alias loop.
- Changing DNS without configuring the destination platform and certificate.
- Leaving a third-party alias behind after deleting the associated resource.
- Testing only through one recursive resolver and overlooking cached data.
Conclusion
A CNAME record is a clean way to make one DNS name follow another, especially for subdomains connected to managed platforms. Its simplicity depends on respecting strict boundaries: the target must be a hostname, the alias cannot carry unrelated data, the apex needs a different solution, and every dependency must remain controlled. Keep chains short, plan TTL changes, configure the destination service, test the full resolution path, and remove obsolete aliases promptly.