What Is a CNAME Record? When to Use One

A CNAME record points one domain name to another domain name. Instead of mapping a hostname directly to an IP address (like an A record does), a CNAME creates an alias. When a DNS resolver encounters a CNAME, it follows the chain and looks up the target domain to find the actual IP address.

The name stands for "Canonical Name." The idea is that one domain is the "real" name (the canonical name), and the CNAME record creates an alias that points to it. This is one of the most commonly used DNS record types, and it is also one of the most commonly misconfigured. For a broader overview of all record types, see DNS Record Types Explained.

How a CNAME Record Looks

A CNAME record has the same basic structure as other DNS records: a name, TTL, class, record type, and a target.

blog.example.com.    3600    IN    CNAME    example.com.

Breaking this down:

• blog.example.com. is the alias (the name you want to redirect)
• 3600 is the TTL in seconds (1 hour)
• IN is the class (Internet)
• CNAME is the record type
• example.com. is the canonical name (the target domain)

The target must always be a domain name, never an IP address. If you need to point directly to an IP address, use an A record (for IPv4) or an AAAA record (for IPv6).

How CNAME Resolution Works

When a user types blog.example.com into their browser, the DNS resolution process follows a chain.

1. The resolver queries the authoritative nameserver for blog.example.com.
2. The nameserver responds with a CNAME record pointing to example.com.
3. The resolver now queries for the A (or AAAA) record of example.com.
4. The nameserver responds with the IP address.
5. The resolver returns the IP address to the browser.

This is called CNAME chaining. The resolver has to make at least one extra lookup to follow the alias. In practice, many DNS servers include the final A record in the additional section of the CNAME response, so the resolver does not always need a second round trip. But the extra step is still there, and it adds a small amount of latency compared to querying an A record directly.

You can see this chain in action with a quick dig command:

dig blog.example.com

;; ANSWER SECTION:
blog.example.com.   3600    IN    CNAME    example.com.
example.com.        3600    IN    A        93.184.216.34

The answer section shows both the CNAME and the resolved A record. If you want to learn more ways to inspect DNS records, see How to Check DNS Records.

CNAME Chains

It is technically possible to chain multiple CNAMEs together. For example:

alias1.example.com.    CNAME    alias2.example.com.
alias2.example.com.    CNAME    target.example.com.
target.example.com.    A        93.184.216.34

This works, but it is a bad idea. Each link in the chain adds another DNS lookup, increasing latency. RFC 1034 advises against CNAME chains, and some resolvers impose limits on how many levels they will follow before giving up. Keep your CNAMEs to a single hop.

When to Use a CNAME Record

CNAMEs are the right tool when you want one hostname to always resolve to the same place as another hostname. Here are the most common scenarios.

Pointing to a CDN

When you set up a CDN like Cloudflare, Fastly, or AWS CloudFront, the provider gives you a target hostname. You create a CNAME pointing your domain to that target.

cdn.example.com.    CNAME    d123456.cloudfront.net.

If the CDN provider changes the underlying IP addresses (which they do regularly for load balancing and failover), your domain automatically follows because it points to the CDN's hostname, not to a specific IP.

Connecting SaaS Services

SaaS platforms frequently ask you to create a CNAME record for custom domain setup. When you configure a custom domain on Shopify, HubSpot, GitHub Pages, or similar services, you will point your domain to theirs.

shop.example.com.    CNAME    shops.myshopify.com.

This lets the SaaS provider manage the IP addresses and infrastructure behind the scenes. You do not need to update your DNS when they scale or migrate servers.

The www Subdomain

One of the most common CNAME uses is pointing the www version of your domain to the apex (bare) domain, or vice versa.

www.example.com.    CNAME    example.com.

This keeps both versions of your domain pointing to the same server. When you change the A record for example.com, the www version follows automatically.

Development and Staging Environments

CNAMEs are useful for pointing subdomains to different environments without managing IP addresses for each one.

staging.example.com.    CNAME    my-app-staging.herokuapp.com.
dev.example.com.        CNAME    my-app-dev.herokuapp.com.

The Zone Apex Restriction

This is the single most important thing to understand about CNAME records: a CNAME cannot coexist with any other record type at the same name.

This rule comes from RFC 1034. The zone apex (also called the naked domain or bare domain) is the domain without any subdomain prefix -- just example.com. Every zone apex must have at least an SOA record and usually NS records. Since a CNAME cannot share a name with other record types, you cannot put a CNAME at the zone apex.

This means the following configuration is invalid:

# This will NOT work
example.com.    SOA    ...
example.com.    NS     ns1.provider.com.
example.com.    CNAME  other.example.net.

The CNAME conflicts with the SOA and NS records. Your DNS provider will reject this configuration, or if it does not, resolvers will produce unpredictable results.

This is a real problem. Many CDN and SaaS providers give you a hostname to point to, but if you want your apex domain (not just a subdomain) to use their service, a standard CNAME will not work.

ALIAS and ANAME Records: The Workaround

To solve the apex CNAME problem, some DNS providers offer proprietary record types called ALIAS or ANAME. These records work like a CNAME at the DNS provider level -- they resolve the target hostname to an IP address and return that IP as if it were an A record. The resolver never sees a CNAME; it gets a plain A record response.

# ALIAS record at apex (provider-specific)
example.com.    ALIAS    loadbalancer.cdn-provider.com.

From the resolver's perspective, this looks like:

example.com.    A    198.51.100.42

The DNS provider handles the translation behind the scenes. This approach works, but it has trade-offs:

• Not standardized. ALIAS/ANAME is not defined in any RFC. Different providers implement it differently.
• TTL behavior varies. Some providers use the TTL of the target, others use their own.
• Health checking depends on the provider. If the target hostname changes IPs, how quickly your ALIAS record reflects that depends on how often your DNS provider re-resolves it.

Cloudflare calls their version "CNAME flattening." Route 53 calls it an "Alias record." Netlify and Vercel handle it automatically. If you need apex domain pointing to a service that only gives you a hostname, check whether your DNS provider supports one of these alternatives.

CNAME vs A Record

The choice between a CNAME and an A record comes down to whether you want to point to a hostname or an IP address.

| Feature | CNAME | A Record | |---------|-------|----------| | Points to | Another domain name | An IP address (IPv4) | | Use at zone apex | No | Yes | | Follows target changes | Yes, automatically | No, must update manually | | Extra DNS lookup | Yes (one more hop) | No | | Can coexist with other records | No | Yes | | Best for | CDNs, SaaS, aliases | Direct server pointing |

Use an A record when you control the server and its IP address is stable. Use a CNAME when you are pointing to a service managed by someone else and you want to automatically follow their infrastructure changes.

If you manage multiple subdomains and want to keep things simple, CNAMEs reduce the number of places you need to update when infrastructure changes. But if performance is critical and you want to eliminate that extra DNS hop, A records are faster. For a deeper look at DNS fundamentals, see the DNS Guide.

Common CNAME Mistakes

Putting a CNAME at the Apex

As covered above, this breaks DNS. If you need your apex domain to point to a hostname, use an ALIAS/ANAME record or Cloudflare's CNAME flattening.

CNAME Alongside MX or TXT Records

Because a CNAME cannot coexist with other record types at the same name, you cannot have a CNAME and an MX record on the same subdomain. This commonly trips people up when setting up a subdomain for both a web service (CNAME) and email (MX).

# This will NOT work
mail.example.com.    CNAME    mailprovider.com.
mail.example.com.    MX       10 mx1.mailprovider.com.

The solution is to use separate subdomains for the web service and email, or use an A record instead of the CNAME.

Long CNAME Chains

Chaining three or four CNAMEs together works in theory but creates fragile, slow DNS resolution. Each link is a point of failure. Keep it to one hop.

Forgetting to Update the Target

A CNAME is only as reliable as the domain it points to. If you create a CNAME to old-service.provider.com and later that hostname gets decommissioned, your CNAME will resolve to nothing. Monitor your CNAME targets and clean up stale records. Dangling CNAMEs pointing to decommissioned services can also be a security risk -- an attacker could register the expired target domain and serve their own content on your subdomain.

Checking Your CNAME Records

You can verify CNAME records using standard DNS tools.

# Using dig
dig blog.example.com CNAME

# Using nslookup
nslookup -type=cname blog.example.com

# Using host
host -t cname blog.example.com

If the CNAME is set up correctly, you will see the target domain in the response. If you get an empty answer, either the record does not exist or it has been replaced with a different record type.

For a full walkthrough of DNS querying tools, see How to Check DNS Records.

Summary

A CNAME record creates an alias from one domain name to another. It is the right choice when you are pointing to a service that manages its own IP addresses, like a CDN, SaaS platform, or cloud service. The main restrictions to remember: you cannot use a CNAME at the zone apex, and a CNAME cannot share a name with any other record type. For apex domains, look into ALIAS/ANAME records or CNAME flattening from your DNS provider.

References

• RFC 1034, "Domain Names - Concepts and Facilities," https://www.rfc-editor.org/rfc/rfc1034