DNS CNAME Record Explained — Aliases and Canonical Names

A CNAME (Canonical Name) record maps one domain name to another, creating an alias that tells DNS resolvers to look up the target name instead. Rather than returning an IP address directly, a CNAME delegates resolution to a different hostname -- the canonical name -- which ultimately resolves to an A or AAAA record.

CNAME records are one of the most widely used DNS record types, particularly for pointing subdomains at third-party services, CDNs, and load balancers.

How CNAME Resolution Works

When a resolver encounters a CNAME, it restarts the lookup using the target hostname. Consider this zone configuration:

shop.example.com.    3600    IN    CNAME    storefront.myshopify.com.

The resolution process unfolds in several steps:

1. A client queries shop.example.com
2. The authoritative nameserver returns the CNAME record pointing to storefront.myshopify.com
3. The resolver now queries storefront.myshopify.com for an A or AAAA record
4. Shopify's nameserver returns the IP address (e.g., 23.227.38.65)
5. The resolver returns both the CNAME and the final A record to the client

This extra lookup is called CNAME chasing. The resolver transparently follows the chain so the client receives the final IP address.

Tip: Because each CNAME adds a DNS round-trip, a single alias is usually fine, but chaining multiple CNAMEs together introduces measurable latency. Keep chains short -- ideally one hop.

CNAME Record Syntax and Format

The wire format for a CNAME record is straightforward:

<name>    <TTL>    IN    CNAME    <canonical-name>

A concrete example:

www.example.com.      3600    IN    CNAME    example.com.
status.example.com.   3600    IN    CNAME    stats.uptimerobot.com.

Common Use Cases

Pointing www to the Apex Domain

The most classic CNAME use case is making www.example.com resolve to the same place as the bare domain. You create an A record on the apex and a CNAME on www:

example.com.        3600    IN    A        192.0.2.1
www.example.com.    3600    IN    CNAME    example.com.

When the server's IP changes, you only update the A record in one place.

CDN Integration

Content delivery networks assign you a provider-specific hostname. A CNAME lets you serve content from your own subdomain while the CDN handles routing:

assets.example.com.    300    IN    CNAME    d111111abcdef8.cloudfront.net.
images.example.com.    300    IN    CNAME    example.b-cdn.net.

Use a shorter TTL here so CDN endpoint changes propagate quickly.

SaaS and Cloud Service Integration

Most SaaS platforms ask you to verify domain ownership and route traffic using CNAME records:

docs.example.com.      3600    IN    CNAME    custom.gitbook.com.
support.example.com.   3600    IN    CNAME    example.zendesk.com.
app.example.com.       3600    IN    CNAME    cname.vercel-dns.com.

This pattern is also common for email services that require domain verification:

em1234.example.com.    3600    IN    CNAME    u1234567.wl.sendgrid.net.
s1._domainkey.example.com. 3600 IN CNAME    s1.domainkey.u1234567.wl.sendgrid.net.

Load Balancer Targets

Cloud providers expose load balancers as hostnames rather than static IPs. A CNAME bridges your domain to the load balancer:

api.example.com.    60    IN    CNAME    my-lb-123456.eu-west-1.elb.amazonaws.com.

The Apex Domain Restriction

The most important CNAME limitation is that you cannot place a CNAME at the zone apex (the bare domain, e.g., example.com). This restriction exists because the DNS specification (RFC 1034) requires that a CNAME be the only record at a given name, but every zone apex must have SOA and NS records.

# This is INVALID -- SOA and NS already exist at the apex
example.com.    CNAME    other-host.example.net.

If you create a CNAME at the apex, it conflicts with the mandatory SOA and NS records, breaking the entire zone.

The Solution: CNAME Flattening and ALIAS Records

To get CNAME-like behavior at the apex, DNS providers introduced non-standard record types that resolve the target at the authoritative server and return A/AAAA records directly:

• ALIAS / ANAME records -- DNScale and many providers support these
• CNAME flattening -- the authoritative server transparently resolves the CNAME target and returns the IP

With DNScale, you can use an ALIAS record at the apex:

example.com.    3600    IN    ALIAS    myapp.herokuapp.com.

The authoritative server resolves myapp.herokuapp.com behind the scenes and returns the resulting A/AAAA records to the client. This is fully transparent to resolvers. For a deeper comparison, see CNAME vs A Record.

CNAME vs A Record Trade-Offs

When to use a CNAME: subdomains pointing to services whose IP addresses are managed by a third party or may change.

When to use an A record: the zone apex, performance-critical hostnames, or when you control the IP and it is stable. See also the AAAA record for IPv6 equivalents.

CNAME Chaining

A CNAME can point to another CNAME, forming a chain:

shop.example.com.           CNAME    storefront.provider.com.
storefront.provider.com.    CNAME    lb.us-east.provider.com.
lb.us-east.provider.com.    A        198.51.100.42

The resolver follows each hop until it reaches an A or AAAA record. While the DNS protocol allows this, chaining introduces problems:

• Latency -- each hop may require a separate query to a different authoritative server
• Fragility -- if any link in the chain becomes unreachable or misconfigured, the entire resolution fails
• Debugging difficulty -- tracing resolution across multiple providers is harder

Tip: Aim for at most one CNAME hop under your control. You cannot control how many additional hops the target provider adds, so keeping your side minimal avoids compounding latency.

Performance Implications

Every CNAME lookup adds latency because the resolver must perform at least one additional query. In practice, the impact depends on several factors:

• Resolver caching -- if both the CNAME and the target A record are cached, there is no additional round-trip. Choose TTL values that balance freshness against cache hit rates.
• Geographic distance -- if the CNAME target is hosted by a provider with anycast DNS, the additional lookup is fast. If the target's authoritative server is far away, the penalty grows.
• DNS propagation -- when you change a CNAME target, both the old CNAME TTL and the old target's TTL must expire before clients see the new destination.

For latency-sensitive services like APIs, consider using A/AAAA records directly rather than a CNAME, especially if you control the IP addresses.

Verifying CNAME Records with dig

The dig command is the standard tool for inspecting CNAME records. Here are practical examples.

Look up a CNAME record:

dig CNAME www.example.com

The answer section shows the alias and its target:

;; ANSWER SECTION:
www.example.com.    3600    IN    CNAME    example.com.

Follow the full resolution chain:

dig www.example.com +trace

This traces every step from the root servers through to the final A record, showing each CNAME hop along the way.

Query a specific nameserver (useful during DNS propagation):

dig CNAME www.example.com @ns1.dnscale.eu

Check that no conflicting records exist at the same name:

dig ANY www.example.com

If you see both a CNAME and another record type (A, TXT, MX) at the same name, the zone is misconfigured.

Verify the target resolves correctly:

dig A storefront.myshopify.com

Always confirm the CNAME target actually has an A or AAAA record. A dangling CNAME pointing to a nonexistent hostname returns NXDOMAIN.

Common Mistakes

1. CNAME at the Apex

Placing a CNAME at example.com breaks SOA and NS resolution. Use an ALIAS record instead.

2. Mixing CNAME with Other Records

A CNAME must be the only record at that name. Adding an MX record or TXT record alongside a CNAME violates the DNS standard and causes unpredictable behavior:

# INVALID -- CNAME cannot coexist with MX
mail.example.com.    CNAME    mailhost.provider.com.
mail.example.com.    MX       10 mailhost.provider.com.

If you need both a CNAME and other record types at the same name, switch the CNAME to an A record.

3. Pointing MX to a CNAME Target

While the MX record must point to a hostname, that hostname should resolve to an A/AAAA record -- not a CNAME. RFC 2181 and RFC 5321 prohibit MX targets that are themselves CNAMEs, and some mail servers refuse delivery in this case.

4. Dangling CNAMEs

When you decommission a service, remove the CNAME that pointed to it. A dangling CNAME pointing to a hostname you no longer control is a security risk -- an attacker can register that target and serve content on your subdomain. This is known as subdomain takeover.

5. Excessively Long CNAME Chains

Some resolvers give up after following too many CNAME hops (typically 8-16). Keep chains short and within a single provider when possible.

Managing CNAME Records with DNScale

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Set Type to CNAME
4. Enter the subdomain in Name (e.g., www, blog)
5. Enter the target hostname in Content
6. Set an appropriate TTL
7. Click Create Record

Using the API

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "www",
    "type": "CNAME",
    "content": "example.com",
    "ttl": 3600
  }'

Related Record Types

• A Record -- maps a name directly to an IPv4 address
• AAAA Record -- maps a name to an IPv6 address
• ALIAS Record -- CNAME-like behavior at the zone apex
• MX Record -- directs email to mail servers (must not point to a CNAME)
• TXT Record -- cannot coexist with a CNAME at the same name
• NS Record -- delegates a subdomain to other nameservers

Conclusion

CNAME records are essential for integrating subdomains with CDNs, SaaS platforms, and cloud services. They simplify maintenance by letting you update a single target hostname instead of changing IP addresses across dozens of records. However, the apex restriction, the no-coexistence rule, and the extra lookup latency mean CNAMEs are not always the right choice. For the zone apex, use an ALIAS record. For stable, performance-critical mappings, use A or AAAA records directly. Understanding these trade-offs ensures your DNS configuration is both correct and performant.