Online Tool Store
· 4 min read
How to Trace a CNAME Chain to Its Final Record
Heshan Fernando
Co-founder & COO
Your site points at a CDN. The CDN points at a load balancer. The load balancer points at a regional endpoint. Three CNAMEs before anything resolves to an actual address, and every one of them is a lookup that has to complete before the browser can open a connection.
Nobody designs a three-hop chain. They accumulate, one vendor at a time.
What each hop costs
A CNAME says “this name is an alias for that name”. The resolver has to look up the target, and if that’s also a CNAME, look up its target, until it reaches an A or AAAA record with an actual address.
On a warm cache this is free. On a cold cache — a first visit, or after the TTL expires — each hop is a round trip to a DNS server. Three hops can add tens of milliseconds before the connection even starts, and that’s before TLS negotiation.
It also compounds a reliability question. Each hop is a name controlled by someone, and any of them failing to resolve takes your site down. A three-hop chain has three parties who can break your DNS, and you may only have a relationship with one of them.
Why the apex can’t be a CNAME
The domain apex — example.com with no subdomain — needs SOA and NS records. A CNAME can’t coexist with other records for the same name, because the whole point of a CNAME is that everything for that name comes from the target.
So example.com CNAME cdn.provider.net is invalid DNS, and this trips up everyone pointing an apex at a hosted service.
Providers work around it with ALIAS or ANAME records — a CNAME-like record at the apex that the authoritative server resolves internally, returning A records to the client. It behaves like what you wanted and it’s a provider feature rather than a DNS standard, so the name and behaviour vary.
The other workaround is a redirect: point the apex at a server that redirects to www, and put the CNAME there. That costs a redirect on every apex request and it works everywhere.
| Situation | Option | Note |
|---|---|---|
www pointing at a service | CNAME | Standard, works everywhere |
| Apex pointing at a service | ALIAS / ANAME | Provider-specific |
| Apex, no ALIAS available | Redirect to www | Costs a redirect |
| Chain of 3+ hops | Flatten if possible | Latency and fragility |
Loops
Two names pointing at each other. Resolvers detect it and fail, which presents as an unresolvable host rather than a helpful error.
It almost always happens during a migration where one side is updated and the other isn’t, and it can be intermittent if different resolvers have different cached states.
Common mistakes to avoid
- Accepting a chain that grows every time a vendor is added.
- Putting a CNAME at the apex and wondering why the zone is rejected.
- Assuming ALIAS behaves identically across providers — it doesn’t, particularly around TTL handling.
- Testing from a machine with a warm cache, which hides the latency entirely.
- Deleting an intermediate name during a migration before the chain has been repointed.
How to do it with CNAME Chain Checker
The CNAME Chain Checker follows the chain and reports each hop.
- Enter the hostname you want to trace.
- Read every hop — each is an extra lookup before the connection starts.
- Check the chain ends in an A or AAAA record that actually resolves.
- Flatten where you can; each hop is both latency and another party who can break it.
RFC 1034 is where the CNAME restrictions are defined, if you need to cite them to a vendor. Other network tools are in the tools directory.
Frequently asked questions
How many CNAME hops are too many?
More than two or three is worth questioning. Each hop costs a lookup, and long chains usually mean a vendor pointing at a vendor — each of whom can take your hostname down.
Why can’t a CNAME sit at the domain apex?
Because the apex must carry SOA and NS records, and a CNAME can’t coexist with other records for the same name. Providers offer ALIAS or ANAME as a workaround.
What causes a CNAME loop?
Two names pointing at each other, usually after a migration where one side was updated and the other wasn’t. Resolvers detect it and fail, which presents as an unresolvable host.
Final thought
Trace the chain on a cold cache before you add another hop. The latency is invisible from your own machine and entirely real for a first-time visitor.