DNS
CNAME chain follower
Follow a CNAME chain hop by hop to its final address, and catch a loop or a dead end before anything fetches it.
Free, no accountLive check
Result
The verdict appears here once you press Follow the CNAME chain.
What this is
This cname lookup chain tool walks a name's CNAME records one hop at a time, the same way a resolver does, stopping only once it reaches a final address, a name that does not exist, or a hop it has already seen before.
A CNAME record points a name at another name rather than at an address, and RFC 1034 §3.6.2 allows that target to be a CNAME itself, so one alias can sit on top of another. A resolver has to follow every one of those in turn before it has anything it can actually connect to.
Nothing about the protocol limits how many hops a chain may have, which is exactly the problem: a chain that nests a CDN behind a load balancer behind a vanity domain can quietly grow to half a dozen hops, each one a separate round trip before the real address is known.
For where the apex rule this chain can run into comes from, and the other record types a domain carries alongside its CNAMEs, see our blog guide "The DNS records a domain needs, and what each one actually does."
How to read the result
The tree below lists every hop in order, each one noting what it pointed at next, with the last node carrying either the final addresses or whatever stopped the walk - a missing name, a loop, or the ten-hop ceiling this check enforces on itself.
Each extra hop shown is a DNS lookup a visitor pays for before a browser can even open a connection to fetch anything, so a short chain is not just tidier, it is measurably faster for every single visit.
Common mistakes
What goes wrong most often, and how to tell.
- Treating a CNAME chain as freeEvery hop in the chain is a separate DNS round trip that has to finish before a browser can open a connection, let alone request a page. A three-hop chain is three sequential lookups slower than pointing the name straight at its target.
- Not noticing a chain loops back on itselfTwo names that alias each other never reach an address, however long you wait - there is nothing to cache and nothing to time out. A resolver that detects the loop simply refuses to answer the name at all.
- Letting an old alias point at a name that was deletedA CNAME target that stops existing leaves the alias dangling: the chain is followed correctly, it just ends at a name with nothing there, which looks identical to a typo from outside.
Questions
What people ask about this tool.
- Each service it passes through - a CDN in front of a load balancer in front of a hosting platform - commonly adds its own CNAME target rather than handing back a plain address, so the hops stack up one provider at a time.
- Two or more names end up aliasing each other, so following the chain keeps arriving back at a name it already visited rather than ever reaching an address. A resolver that notices stops and refuses to answer rather than loop forever.
- No fixed number comes from the DNS protocol itself, but most resolvers give up well before an unreasonable depth, so a chain that keeps growing eventually fails for ordinary visitors even though each individual hop was configured correctly.
- The alias was pointed at a name that has since been removed or was never created, so the chain resolves exactly as configured and still ends at nothing - the fix is pointing it at a name that is actually there.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- IETF, “RFC 1034: Domain Names - Concepts and Facilities” read 13 October 2026
- IETF, “RFC 1912: Common DNS Operational and Configuration Errors” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.