CNAME Record Lookup

A CNAME (Canonical Name) record creates an alias: when a resolver queries shop.example.com and finds a CNAME pointing to stores.shopify.com, it discards the original name and re-queries stores.shopify.com for its address records. The queried name is just a pointer — the target name does the actual work. This indirection is how every CDN, managed hosting platform, and SaaS service connects a customer's custom domain to infrastructure they control. Vercel, Netlify, Shopify, GitHub Pages, Cloudflare, Fastly, and CloudFront all use the same pattern: they give you a CNAME target to add to your DNS, and their load balancers route traffic based on which customer's CNAME points to them.

Verifying a custom domain setup

When you configure a custom domain on a hosting platform, the most common failure point is the CNAME not being created, or pointing to the wrong target. Platforms typically show you the expected target (for example, cname.vercel-dns.com or shops.myshopify.com) during onboarding. Checking it yourself tells you immediately whether DNS has propagated yet, whether the record was entered at the wrong subdomain, or whether the target value contains a typo. This tool queries a public DNS-over-HTTPS resolver in real time — your local machine's cached DNS does not affect the result.

CNAME chains

Some CNAME records point to other CNAME records rather than directly to A or AAAA records — this is called a CNAME chain. Cloudflare's custom hostname feature, for example, often produces two or three hops before the resolver reaches an IP address. Resolvers follow chains transparently, so the end user sees no difference in behavior — but each hop adds a round-trip DNS resolution for uncached queries. Most CDN providers keep chains short (one or two hops) for performance. If a lookup returns a CNAME target that itself has a CNAME, you can look up that target separately to follow the full chain.

What CNAMEs cannot do

RFC 1034 prohibits CNAME records at a zone apex (root domain). You can set a CNAME at www.example.com but not at example.com itself. The restriction exists because a CNAME owns the entire name — no other record type can coexist with it — and a root domain must always carry SOA and NS records. Several DNS providers implement a proprietary workaround called CNAME flattening (also called ALIAS or ANAME records) that behaves like a CNAME at the apex while remaining spec-compliant.

The same exclusivity rule blocks MX records. A hostname that already has a CNAME cannot also have an MX record. If you need both a CNAME-style alias and email or SPF on the same hostname, you need to replace the CNAME with A/AAAA records pointing to the same destination IP. Attempting to add an MX record alongside a CNAME is a misconfiguration that most DNS providers will reject or silently ignore.

Identifying a hosting provider from a CNAME target

The canonical target often reveals which platform a subdomain uses. *.vercel-dns.com means Vercel. *.netlify.com or *.netlify.app means Netlify. shops.myshopify.com means Shopify. ghs.googlehosted.com means Google Sites or a legacy Google Apps setup. *.cloudfront.net means AWS CloudFront. *.azureedge.net means Azure CDN. This lookup is publicly available information — no credentials or special access are required to see where a subdomain is hosted.