An A record gives a DNS name an IPv4 address. A CNAME record makes one DNS name an alias of another DNS name. A CNAME target is a domain name, not an IPv4 literal.

The choice depends on who manages the destination address and whether the name needs other DNS records. An alias can follow address changes managed elsewhere, but it also makes resolution depend on the target name. Neither a direct address nor an alias proves that the application at the destination is reachable.

Address Data versus an Alias

Suppose app.example.com has an A record containing 192.0.2.10. A lookup for type A at that name can return that IPv4 address directly. The example uses an IPv4 address reserved for documentation. If the service moves to another IPv4 address, the zone operator updates the A record, but resolvers can normally keep using the old address until the cached record's TTL expires.

Now suppose app.example.com has a CNAME record pointing to service.example.net. A lookup for an address at app.example.com encounters the alias, then continues to the canonical target for its address data. The target may have an A record, an AAAA record or other relevant data. Changing the target's address can affect users of the alias without editing the alias record itself, once relevant cached data is refreshed.

This makes a CNAME useful when an operator wants a name to track a target managed in another zone or by another service team. Writing app.example.com CNAME 192.0.2.10 does not publish an IPv4 address: the CNAME value is interpreted as a DNS name. Use an A record for a direct IPv4 address or an AAAA record for a direct IPv6 address.

There can be several A records at a name, forming an A resource record set, or RRset. An alias name can have only one CNAME target. The target can itself have multiple address records, so one alias can ultimately lead to several addresses. The DNS response may include both the CNAME and address data when the server has it available, but an application still has to use the resulting address to connect.

How CNAME Chains Affect DNS Lookups

A chain occurs when one alias points to a second alias before reaching a name with the requested address. For example, shop.example.com can point to edge.example.net, which points to host.example.org, which finally has an A record. Each step adds another name to resolve and another record set that may be missing, misconfigured or cached for a different length of time.

Resolvers can cache intermediate CNAMEs and address data, so a chain does not always add a separate network round trip for every visit. On a cold lookup, however, extra targets can require more resolution work. The added delay depends on cache state, resolver behavior and where the target data is available, so there is no fixed time penalty for every chain. A longer chain also makes troubleshooting harder because the final address may change at a name far from the one the user typed.

Read a chain from the original name to the final canonical name, checking each target and whether it exists. If a target is misspelled or removed, the starting alias can be present while the final address lookup fails. If a chain circles back to an earlier name, the lookup cannot reach a usable final answer. Keeping only the alias steps the service requires reduces the number of names that must remain correctly configured.

Separate TTLs for the Alias and Address

An A RRset has its own TTL, which controls how long a resolver can normally cache it. A CNAME record and its target address RRset have separate TTLs that need not match. A resolver can still have the CNAME cached when the target's A record needs to be refreshed. It can also hold an older alias target while the new target's address data is already available elsewhere.

Editing the CNAME to point to a new canonical name does not erase old CNAME copies already cached under the previous TTL. Editing the target A record does not automatically refresh the alias RRset, although the alias may not need to change. When comparing two results, record the CNAME target, final address and remaining TTLs separately.

A direct A record avoids the separate alias step and is appropriate when the address is managed directly at that owner name. A CNAME can reduce repeated address maintenance across several names, but the target's operator controls which addresses those aliases eventually return. If a hosting provider requires its hostname as the target, copying the provider's current IP address into an A record can miss later address changes.

Check Which Names Can Hold a CNAME

The name that owns a CNAME cannot also hold ordinary records such as A, AAAA, MX, TXT or NS at that same name. DNSSEC signature records can accompany a CNAME. The apex, or top-level name of a DNS zone, already needs SOA and authoritative NS records, so it cannot hold a standard CNAME.

A name used as the target of an MX or NS record must have the required address records rather than be a CNAME alias. An MX record identifies a mail server, while an NS record identifies a nameserver. This restriction concerns the target named inside those records, as well as the separate rule against placing MX or NS data at a CNAME's owner name.

Some DNS providers offer apex aliasing or CNAME flattening as a separate service. A flattening service can resolve the configured target and return A or AAAA address records to a client instead of a CNAME. Check the provider's behavior for the record types your service needs, particularly if a verification service expects to see the CNAME itself.