A Records and CNAME Records: Choosing a DNS Target

An A record and a CNAME can both help a client reach a service, but they publish different kinds of DNS data. An A record contains an IPv4 address. A CNAME says that one DNS name is an alias of another DNS name.

That distinction affects infrastructure changes, what other records may exist at the same name, how the zone apex is handled, and what to inspect when a request reaches the wrong application.

Gather the decision inputs

Before selecting a record, identify:

• the exact public name, such as api.example.com
• whether the destination was supplied as an IPv4 address or a hostname
• whether the provider documents a specific record or proprietary alias feature
• whether the name is a subdomain or the zone apex
• which system will issue TLS for the public name

If the destination owner cannot provide a supported DNS target, publishing a guessed record usually makes ownership and incident response harder.

Record semantics at a glance

Property	A record	CNAME record
Stored value	IPv4 address	Canonical DNS name
Typical example	203.0.113.42	tenant.hosting.example.
Address changes	Zone operator updates the A record	Target operator can update address records behind its hostname
Other data at the same owner name	May coexist when DNS rules permit	Standard CNAME owner name cannot contain other record data
Zone apex	Valid	Standard DNS does not permit a CNAME at the apex

An AAAA record is the IPv6 counterpart to an A record. Do not put an IPv6 address into an A record or assume that adding only an A record provides IPv6 reachability.

Use an A record for a documented IPv4 target

An A record is appropriate when the service contract is an IPv4 address that you control or are expected to publish directly:

api.example.com.    300    IN    A    203.0.113.42

Common examples include a fixed VPS address, a directly addressed load balancer, or an origin whose IP changes are managed by your team.

The operational consequence is simple: when that IP changes, someone with access to the zone must update the record. Keep the previous value and a rollback procedure with the deployment record.

Use a CNAME for a documented hostname target

A CNAME is appropriate when a platform gives you a hostname and instructs you to alias your public name to it:

docs.example.com.    300    IN    CNAME    tenant.hosting.example.

The target operator can change the A or AAAA records behind tenant.hosting.example without asking you to replace the CNAME. Do not resolve the target once and publish the observed address as a substitute unless the provider explicitly documents that approach.

For a full endpoint rollout, continue with the subdomain DNS, routing, and HTTPS workflow after selecting the record.

Account for the zone-apex exception

Standard DNS does not allow a CNAME at the top of a zone such as example.com. The apex already needs records such as SOA and NS, which conflicts with the rule that a CNAME owner name cannot contain other data.

DNS providers offer different alternatives:

• Route 53 alias records can route the apex to selected AWS resources
• Cloudflare can flatten a CNAME and return address records to the resolver
• another provider may expose an ALIAS, ANAME, or product-specific domain connection

These are provider features, not interchangeable standard record types. Check the authoritative provider and destination platform documentation before using one.

A CNAME is not an HTTP redirect

With a CNAME, the browser still requests the original public hostname. DNS resolution may follow the alias, but the address bar does not change to the CNAME target.

The destination must therefore:

• recognize the original Host value
• present a certificate valid for the original public hostname
• generate redirects and callback URLs using the intended public base URL

If the browser should visibly move to a different URL, configure an HTTP redirect at a server, edge rule, or platform layer rather than expecting CNAME behavior to do it.

Illustrated resolver output

Illustrative example using reserved example domains and IPs. The following SVG is a constructed comparison, not terminal output captured from an operating service. Provider-style names shown in it are placeholders.

Illustrative example using reserved example domains and IPs. It is not evidence of a customer or production DNS configuration.

The relevant pattern is the record shape: the A query returns an IPv4 address, while the CNAME query identifies another DNS name that must then resolve.

Inspect each path explicitly

For an A record:

dig api.example.com A +noall +answer

api.example.com.    300    IN    A    203.0.113.42

For a CNAME:

dig docs.example.com CNAME +noall +answer
dig tenant.hosting.example A +noall +answer
dig tenant.hosting.example AAAA +noall +answer

docs.example.com.    300    IN    CNAME    tenant.hosting.example.
tenant.hosting.example.    300    IN    A    198.51.100.24

Use the actual provider target in the second and third commands. A short dig +short query is convenient, but the full answer section is more useful when you need to see record types and remaining TTLs.

Edge cases worth checking

A CNAME conflicts with another record

If docs.example.com already has TXT, MX, or other data, adding a standard CNAME at that exact name is not valid. Inventory the existing record set before changing it.

The provider target was converted into an A record

The current address behind a managed hostname may be temporary, shared, or incomplete. Following the documented CNAME preserves the provider’s routing contract.

DNS is correct but the service rejects the hostname

This points to custom-domain registration, reverse-proxy host matching, TLS, or application configuration. Replacing a correct DNS record will not repair those layers.

A provider-specific alias is mistaken for a CNAME

Route 53 alias records and Cloudflare CNAME flattening can produce address-style answers at the apex, but their configuration and supported targets differ. Document which provider feature the zone uses.

Roll out the selected record

1. capture the current record set and TTL
2. create the provider-documented A, AAAA, CNAME, or supported apex alternative
3. query the intended record type directly
4. compare authoritative and recursive answers
5. verify TLS and the application response for the public hostname

If resolvers disagree, use the DNS cache and propagation guide before changing the record again. If Cloudflare is authoritative, the Cloudflare DNS setup guide explains how proxy status changes the answer a resolver sees.