CNAME look up. Every hop in the alias chain.
Type a hostname and the tool follows each CNAME hop to the final A record, then flags loops, dead ends and chains too deep to trust.
A free online tool by Digital HeroesType a hostname. The tool follows every CNAME hop until it reaches a terminal A record, then flags loops and missing terminals. It reads the same answers as dig CNAME, run once per hop.
Use a sub-domain like www.* or app.*, apex domains usually have A/AAAA, not CNAME.
// no query yet
- RFC 1034, DNS concepts, section 3.6.2 holds the CNAME rule
- Cloudflare CNAME flattening, the apex workaround
- Cloudflare 1.1.1.1 DNS over HTTPS JSON API, the resolver this tool queries
- The tool stops after 10 hops. Two hops or fewer pass, three or four warn, five or more fail.
A CNAME look up finds the hostname an alias points to, then keeps asking until it reaches an A record. Use it when a custom domain on Shopify, Vercel or Netlify will not resolve, or before a DNS cutover. The fact that matters: resolvers refuse a chain that loops, and every extra hop adds a round trip.
CNAME look up, hop by hop: what the chain shows.
A CNAME record says one name is an alias for another. The tool asks the resolver for that alias, then asks again at the target, and repeats until a name answers with an A record. The result is a chain: the hops in order, the record type at each, and the terminal address.
Resolvers follow the alias for you, so a browser never sees the chain. A chain still costs time: each hop is one more question before the address comes back, which is why RFC 1034 tells zone owners to point records at the canonical name rather than at another alias. The checker makes that hidden work visible.
Three things fail the check. A loop, where a hop points back at an earlier name, which makes a resolver give up and return an error. A dead end, where the last name has no A record. And depth: this tool passes two hops or fewer, warns at three or four and fails at five, stricter than any resolver on purpose.
The thresholds come from the custom domain setups we ship. Shopify, Vercel, Netlify and Cloudflare Pages each ask for one CNAME, and Vercel's domain guide pairs that CNAME with a plain A record at the apex. In our builds one hop is the norm and two is the most a provider needs, so a third hop is almost always a leftover from an earlier host.
When to run a CNAME checker.
Run the checker whenever a hostname should point at a provider and does not: a custom domain that shows the provider's default page, a certificate that will not issue, or a www that stopped answering after a migration. Each of those is a chain problem before it is a hosting problem.
| Symptom | What the chain usually shows | Next check |
|---|---|---|
| Custom domain shows the host's default page | The CNAME still points at the old provider, or the target has no A record | Fix the record, then confirm it has spread with the DNS propagation checker |
| SSL certificate will not issue | The provider validates the name and reaches the wrong target | Rerun once the chain ends at the provider, then the HTTPS and SSL checker |
| Mail stops after a DNS change | A name that carries MX or TXT was turned into a CNAME, which RFC 1034 does not allow beside other records | Move the alias to a sub-domain, then read the MX records |
| Root domain refuses a CNAME | The apex holds SOA and NS records, so it cannot be an alias | Use ALIAS or ANAME, Cloudflare flattening, or redirect the apex to www and verify it with the redirect chain checker |
| Store launch or platform cutover | The old CNAME stays cached until its TTL runs out | Lower the TTL ahead of the flip; our Shopify store setup and Shopify migration pages give the sequence |
For mail names the rule cuts both ways: a DKIM selector such as selector1._domainkey can be a CNAME to your provider, because nothing else lives at that name, but the apex that carries MX cannot. The SPF, DKIM and DMARC checker reads those records after you change them.
Reading the result against dig.
The table has four columns: hop, type, host and target. Type is CNAME for an alias, A for the terminal address, and (none) when the last name has no address record at all. The checks under the table repeat the verdict in plain words so you can paste it into a ticket.
Under the hood each hop is one GET to Cloudflare's 1.1.1.1 DNS over HTTPS JSON API, asking for type CNAME and reading record type 5 from the answer, then type A, record type 1, at the end. The numbers are the RFC 1035 type codes, so the same chain appears in a terminal with dig +short CNAME www.github.com, repeated once per target. Checked on 6 October 2026, it answered with one hop to github.com.
Two differences from dig matter. The tool lowercases the hostname and strips the trailing dot from each target, so copy the host column rather than retyping it. And it queries only the IPv4 address at the end, so a name with an AAAA record but no A record reads as a dead end here even though it resolves over IPv6.
For the full record set at one name, including AAAA, use the DNS lookup instead, and the IP lookup to see who owns the terminal address.
Questions about CNAME records.
What is a CNAME look up?
A CNAME look up asks DNS whether a hostname is an alias and, if so, which name it points to. This tool repeats that question at each target until a name returns an A record, then prints the chain as hops. It is the quickest way to see where www or a custom domain really lands.
Is a CNAME lookup the same as a DNS lookup?
No. A DNS lookup asks for every record type at one name: A, AAAA, MX, TXT, NS and so on, which our DNS lookup tool returns in one sweep. A CNAME lookup asks only whether the name is an alias, then follows the alias to its end. Use the full lookup for an inventory and this tool for a chain.
Why does my CNAME chain fail the check?
One of three reasons. The chain loops back to a name it already visited, which resolvers refuse. The last name has no A record, so the alias leads nowhere. Or the chain is five hops or longer, which this tool fails because the providers we deploy on need at most two. Fix the record the table names, then rerun.
Why can the root domain not be a CNAME?
RFC 1034 says a name with a CNAME can hold no other record, and the root of a zone must hold SOA and NS records, so an apex CNAME breaks the zone itself. Providers work around it with ALIAS or ANAME records, Cloudflare flattens the CNAME at the edge, or you redirect the apex to www and alias www instead.
Last reviewed .
DNS cutover on a launch? Book a call.
A store launch or a platform move is a sequence: lower the TTL, stage the new host, flip the alias, reissue the certificate, recheck mail. A 30 minute call puts the steps in order, and a written scope follows within 48 hours.
More from Divyansh.
Chief Technology Officer · Lucknow · 13 posts on the site
Published · Last updated .
