Can a CNAME point to another CNAME?

DNS resolvers can follow CNAME chains. Keep unnecessary dependencies short, avoid loops, and preserve the entry point required by a hosting provider.

Guance Editorial Team 2026-10-27 3 min read Updated 2026-10-27

Best practices

Illustration of application modules working together

Yes. A CNAME can lead to another CNAME, and resolvers can follow the chain to the requested data. Chains are common in managed hosting and CDN services. Avoid unnecessary hops you control, but do not bypass a provider's documented entry point simply because its internal DNS contains another alias.

www.example.com  -> service.example.net
service.example.net -> edge.example.net
edge.example.net -> 203.0.113.10

For an A query, the final result is an IPv4 address; an AAAA query seeks IPv6 addresses. Other query types seek their own requested data. A CNAME query itself need not expand the entire chain.

A hop is not always another network round trip

An answer can include several CNAME records and the final data. A resolver may already have intermediate or final records cached. Therefore, the number of aliases is not a direct count of DNS packets or a fixed latency penalty.

A cold lookup that crosses authoritative services can require additional queries. Each independently managed target also introduces another dependency: expiration, an incorrect record, or a service outage can break resolution farther down the chain.

Keep the chain intentional

For records you manage, remove redundant intermediate names when doing so preserves the intended ownership and migration design. When a CDN or SaaS provider supplies a target, use that target rather than copying an internal edge hostname or current IP address. Internal names may change or depend on provider routing policy.

During a migration, update the public alias to the new provider's documented entry point. Review TTLs, cached answers, and the retirement period for old names. Leaving a series of previous migration aliases makes diagnosis and ownership harder.

RFC 1034 recommends avoiding aliases that point to aliases while requiring implementations to follow them. Do not confuse that recommendation with the stricter rule that MX and NS targets must not be aliases.

Inspect the actual answers

dig www.example.com A
dig www.example.com AAAA
dig +short www.example.com A

Examine the answer section and query intermediate targets when necessary. dig +trace is useful for following delegation, but it is not a universal display of every CNAME dependency. Check the authoritative data as well as the recursive answer when caches obscure a recent change.

HTTP synthetic tests in Guance can help compare observed DNS timing and service reachability across locations. Use DNS queries to establish the chain itself; a successful HTTP check may have used cached data.

Loops and implementation limits

A loop such as a -> b -> a cannot resolve successfully. Resolvers detect loops or enforce work limits and commonly return SERVFAIL; a failure response alone does not prove a loop. Long valid chains can also hit implementation-specific limits, so there is no single portable maximum to rely on.

There is no special HTTP redirect or content move merely because DNS follows a CNAME. The browser still requests the original hostname. Any effect on search crawling or user experience comes through reachability and performance, rather than an assumed SEO benefit or penalty for a particular hop count.