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. For IPv6, the equivalent is the AAAA record, which maps a domain to a 128-bit IPv6 address.

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 but provides a layer of indirection that can simplify management.

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"

This is especially important for email security. SPF, DKIM, and DMARC all rely on TXT records, which cannot coexist with a CNAME.

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. This is one of the biggest advantages of CNAME over A records for services you do not control.

CDN Integration

CDNs distribute content across many edge servers whose IP addresses change frequently. CNAME is the standard way to integrate with a CDN:

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

The CDN uses anycast routing or geographic DNS resolution to direct users to the nearest edge. A CNAME lets the CDN handle this transparently.

For the apex domain with a CDN, use an ALIAS record or configure the CDN to provide static IP addresses you can use with A records.

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. This simplifies management when many subdomains point to the same infrastructure.

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. This is the cleanest solution for pointing an apex domain to a service that provides only a hostname.

HTTPS Records

For web services specifically, HTTPS records in alias mode (priority 0) can point the apex to another hostname:

example.com.  3600  IN  HTTPS  0 cdn.provider.com.

Modern browsers that support HTTPS records will use this for connection setup, though you should still maintain A/AAAA records for backward compatibility.

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, eliminating the extra round trip. The authoritative server often returns both the CNAME and the target A record in a single response.

CNAME Chains

Avoid chaining multiple CNAMEs (A points to B, B points to C). Each link adds latency and increases the chance of a timeout. Most resolvers will follow up to 8-10 CNAME hops, but chains longer than 2-3 are a sign of misconfiguration.

TTL Considerations

With CNAME records, both the CNAME TTL and the target's A record TTL matter. The effective cache time is the minimum of the two. If your CNAME TTL is 3600 but the target's A record has a TTL of 60, resolvers will need to re-resolve every 60 seconds regardless. See DNS TTL Best Practices for guidance.

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 Framework

Use this structured approach when deciding between A and CNAME:

1. Is it the apex/root domain? Use A (or ALIAS)
2. Do you need other records at the same name? Use A (CNAME can't coexist with MX, TXT, etc.)
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
6. Are you integrating with a CDN or cloud platform? Use CNAME for subdomains, ALIAS for apex
7. Do you need DNS-based redirects? Use A records pointing to a redirect server

Common Mistakes

CNAME at the Apex

Creating a CNAME at example.com will break email delivery, DNSSEC, and other services that rely on records at the apex. Some providers silently prevent this; others will create it and cause problems. Always use A or ALIAS at the apex.

CNAME with MX Records

A CNAME at mail.example.com is fine, but a CNAME at a name where you also need MX records is invalid. The CNAME takes precedence and the MX records will be ignored by resolvers.

Forgetting AAAA Records

When using A records, remember to also add AAAA records for IPv6 connectivity. CNAME handles this automatically since the target domain resolves to both A and AAAA. For details on IPv6 considerations, see IPv6 vs IPv4.

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
• HTTPS Record -- modern service binding for web
• SRV Record -- service discovery with port and priority

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.