CNAME Records Explained

A CNAME (Canonical Name) record creates an alias from one domain name to another. Instead of pointing to an IP address like an A record or AAAA record, a CNAME points to another domain name, which is then resolved to get the final IP address. This indirection is what makes CNAMEs both powerful and sometimes tricky.

How CNAME Records Work

When a DNS resolver encounters a CNAME record, it follows the alias to find the actual IP address:

blog.example.com.    3600    CNAME    example.com.
example.com.         3600    A        192.0.2.1

Query flow:

1. Client asks for blog.example.com
2. DNS returns CNAME pointing to example.com
3. DNS then resolves example.com to 192.0.2.1
4. Client connects to 192.0.2.1

The key insight is that a CNAME delegates resolution to the target domain. If example.com changes its IP address, blog.example.com automatically follows -- no update needed on the CNAME itself. This is why CNAMEs are the preferred way to point subdomains to third-party services.

Common Use Cases

Subdomain Aliases

Point multiple subdomains to the same destination:

www.example.com.     3600    CNAME    example.com.
blog.example.com.    3600    CNAME    example.com.
shop.example.com.    3600    CNAME    example.com.

CDN Integration

Point your domain to a CDN provider. CDN providers frequently change the IP addresses behind their hostnames, so a CNAME ensures your DNS always follows:

www.example.com.    3600    CNAME    d1234.cloudfront.net.
static.example.com. 3600    CNAME    example.b-cdn.net.

When setting up a CDN with CNAME, you also need to configure the CDN to accept requests for your domain (often called "custom domain" or "alternate domain name"). The CNAME handles DNS, but the CDN must also be configured to serve your content. You may also need a CAA record to authorize the CDN's certificate authority to issue SSL/TLS certificates for your domain.

Cloud Service Integration

Point subdomains to cloud platforms:

app.example.com.    3600    CNAME    myapp.herokuapp.com.
docs.example.com.   3600    CNAME    example.gitbook.io.
status.example.com. 3600    CNAME    example.statuspage.io.

Email Service Verification

Many email services require CNAME records for DKIM signing and tracking:

em1234.example.com. 3600    CNAME    u1234.wl.sendgrid.net.

Services like SendGrid, Mailgun, and Postmark use CNAMEs to verify your domain and enable features like click tracking. These work alongside your MX records and TXT records for email authentication.

Record Format

Important Limitations

1. Cannot Use at Apex/Root Domain

CNAME records cannot be used at the root domain (apex). This is a fundamental restriction defined in RFC 1034. The reason is that a CNAME must be the only record at a name, but the apex always needs SOA and NS records:

# NOT ALLOWED
example.com.    CNAME    other.com.
 
# ALLOWED
www.example.com.    CNAME    other.com.

For apex domains that need to point to another hostname, use ALIAS records instead. See our detailed comparison in CNAME vs A Record.

2. Must Be the Only Record at That Name

A CNAME cannot coexist with other record types at the same name:

# NOT ALLOWED - conflicts with CNAME
www.example.com.    CNAME    example.com.
www.example.com.    TXT      "verification=abc123"
 
# ALLOWED - CNAME is the only record
www.example.com.    CNAME    example.com.

This means you cannot have a CNAME and an MX record at the same name, or a CNAME and a TXT record. If you need both an alias and other records at the same name, use an ALIAS record or direct A/AAAA records.

3. Adds Lookup Latency

Each CNAME introduces an additional DNS lookup, which can increase latency. For performance-critical applications, consider using A/AAAA records directly.

CNAME Chaining

While DNS technically allows CNAME chains (a CNAME pointing to another CNAME), this is generally discouraged:

blog.example.com.     CNAME    www.example.com.
www.example.com.      CNAME    example.cdn.com.
example.cdn.com.      A        192.0.2.1

Each link in the chain adds another DNS lookup, increasing latency and the chance of failure. Most resolvers handle chains, but some impose limits (e.g., 8 hops). Keep chains as short as possible -- ideally zero.

CNAME Flattening

Some DNS providers, including DNScale with ALIAS records, offer CNAME flattening (sometimes called ALIAS or ANAME). This resolves the CNAME target at the authoritative server and returns the resulting A or AAAA record directly to the client. The benefits are:

• Works at the apex domain (solving the biggest CNAME limitation)
• No extra lookup latency for the client
• Can coexist with other record types

CNAME flattening is a provider-side feature, not a standard DNS record type. DNScale implements this through ALIAS records.

Querying CNAME Records with dig

# Query CNAME records directly
dig CNAME www.example.com
 
# Follow the chain to get the final IP
dig www.example.com +trace
 
# See both the CNAME and the resolved IP
dig www.example.com
 
# Query the authoritative server to verify changes
dig CNAME www.example.com @ns1.dnscale.eu
 
# Get just the target hostname
dig CNAME www.example.com +short

When you run dig www.example.com (without specifying a type), the resolver automatically follows the CNAME and returns both the CNAME record and the final A/AAAA record in the answer:

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

Adding a CNAME Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Enter the subdomain (e.g., www, blog)
   • Type: Select CNAME
   • Value: Enter the target domain name
   • TTL: Set the cache duration (default: 3600)
4. Click Create Record

Using the API

Create a CNAME record:

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
  }'

Point subdomain to CDN:

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": "cdn",
    "type": "CNAME",
    "content": "d1234567.cloudfront.net",
    "ttl": 3600
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "www.example.com.",
      "type": "CNAME",
      "content": "example.com.",
      "ttl": 3600,
      "disabled": false
    }
  }
}

Best Practices

1. Use trailing dots - The target domain should technically end with a dot (e.g., example.com.), though DNScale handles this automatically

2. Check for conflicts - Ensure no other records exist at the CNAME name. DNScale will warn you about conflicts when creating records.

3. Consider TTL carefully - Use shorter TTLs if the target might change (e.g., during CDN migrations). See DNS TTL Best Practices.

4. Don't chain too many CNAMEs - While DNS allows CNAME chains, they add latency and complexity

5. Use ALIAS for apex - If you need CNAME-like behavior at the root domain, use ALIAS records

6. Verify propagation - After creating a CNAME, use dig to verify the change has propagated. See DNS Propagation Explained.

CNAME vs ALIAS vs A Record

For more detail, see CNAME vs A Record.

Troubleshooting CNAME Records

CNAME not working? Check these issues:

1. Conflicting records: Another record (A, TXT, MX, etc.) exists at the same name. Delete the conflicting record first.
2. Apex domain: You may have tried to add a CNAME at the apex. Use an ALIAS or A record instead.
3. Target not resolving: The CNAME target itself must resolve. If target.example.com has no A/AAAA record, the CNAME will fail.
4. SSL mismatch: The target server must serve a valid SSL/TLS certificate that covers your domain name, not just its own.
5. Propagation: Allow time for DNS propagation, or flush your cache to test immediately.

Related Record Types

• A - Direct IPv4 mapping
• AAAA - Direct IPv6 mapping
• ALIAS - CNAME-like behavior for apex domains
• NS - Nameserver delegation
• SRV - Service discovery records
• HTTPS - HTTPS service binding

Conclusion

CNAME records are invaluable for simplifying DNS management, especially when integrating with third-party services like CDNs, cloud platforms, and email providers. Understanding their limitations -- particularly around apex domains and record coexistence -- helps you make the right choice between CNAME, ALIAS, and direct A/AAAA records. With DNScale, creating and managing CNAME records is straightforward, and our platform automatically validates against common misconfigurations.