CNAME vs A Record

CNAME and A records are the two most commonly used DNS record types, but they work in fundamentally different ways. An A record maps a domain to an IP address, while a CNAME record maps a domain to another domain name. Choosing the right one depends on your use case.

Quick Comparison

How A Records Work

An A record directly maps a domain name to an IPv4 address:

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

When a resolver queries example.com, it gets the IP address immediately. One lookup, done.

How CNAME Records Work

A CNAME creates an alias that points to another domain name, which then needs to be resolved:

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

When a resolver queries blog.example.com:

1. It gets the CNAME pointing to example.com
2. It then resolves example.com to get the A record
3. It returns 192.0.2.1

This two-step process adds a small amount of latency.

When to Use A Records

Apex/Root Domain

A records are the standard choice for your root domain (example.com without www):

example.com.  3600  IN  A  192.0.2.1

CNAME records cannot be used at the apex because DNS standards require the apex to have SOA and NS records, and a CNAME cannot coexist with other records at the same name.

When You Know the IP Address

If your server has a static IP that won't change, A records are the most direct and efficient option:

api.example.com.   3600  IN  A  203.0.113.10
mail.example.com.  3600  IN  A  203.0.113.20

When You Need Other Records at the Same Name

Since CNAME cannot coexist with other record types, use an A record if you also need MX, TXT, or other records at the same name:

example.com.  3600  IN  A    192.0.2.1
example.com.  3600  IN  MX   10 mail.example.com.
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

When to Use CNAME Records

Pointing to Cloud Services

Most cloud platforms give you a hostname, not a static IP. Use CNAME to point your subdomain to their hostname:

app.example.com.     3600  CNAME  myapp.herokuapp.com.
docs.example.com.    3600  CNAME  example.gitbook.io.
shop.example.com.    3600  CNAME  shops.myshopify.com.

If the cloud provider changes their IP addresses, your DNS automatically follows — no update needed on your end.

CDN Integration

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

When the Target IP May Change

If the destination server's IP address changes frequently, a CNAME lets the target domain handle the resolution. You never need to update your DNS.

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.

If you later change the IP of example.com, all subdomains follow automatically.

What About the Apex Domain Problem?

The biggest limitation of CNAME is that it cannot be used at the root domain. This creates a problem when you want CNAME-like behavior for example.com (without www).

Solutions:

ALIAS Records (Recommended)

DNScale supports ALIAS records, which work like CNAME at the apex but are resolved by the authoritative server:

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

The authoritative server resolves the target and returns the IP as if it were an A record, so it coexists with other record types.

Multiple A Records

If ALIAS isn't available, use A records pointing to the service's IP addresses. The downside is you must update them manually if the IPs change.

Performance Comparison

A record lookup:     Client → Resolver → Authoritative → IP returned
                     (1 lookup)
 
CNAME lookup:        Client → Resolver → Authoritative → CNAME returned
                     Client → Resolver → Authoritative → IP returned
                     (2 lookups, though often optimized by resolvers)

In practice, the performance difference is minimal. Most resolvers optimize CNAME resolution by including the final A record in the additional section of the response.

Managing Both in DNScale

Using the Dashboard

1. Navigate to your zone
2. Click Add Record
3. Select A or CNAME as the type
4. Fill in the name and value
5. Click Create Record

Using the API

A 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": "A",
    "content": "192.0.2.1",
    "ttl": 3600
  }'

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": "blog",
    "type": "CNAME",
    "content": "example.com",
    "ttl": 3600
  }'

Decision Flowchart

1. Is it the apex/root domain? → Use A (or ALIAS)
2. Do you need other records at the same name? → Use A
3. Is the target a hostname (not an IP)? → Use CNAME
4. Might the target IP change? → Use CNAME
5. Is it a static IP you control? → Use A

Related Record Types

• A Record — map a domain to an IPv4 address
• AAAA Record — map a domain to an IPv6 address
• CNAME Record — create domain name aliases
• ALIAS Record — CNAME-like behavior for apex domains

Conclusion

A records and CNAME records each have clear strengths. Use A records for apex domains, static IPs, and when you need to coexist with other record types. Use CNAME for subdomains pointing to third-party services where the target IP may change. When you need the best of both worlds at the apex, use DNScale's ALIAS record support.