CNAME Record Checker

Probe common sub-hosts, follow each alias to its final target, and spot dangling records, long chains and apex-CNAME conflicts.

Try an example: status.github.com · shop.tesla.com · help.linkedin.com · www.airbnb.com

Check a custom hostname

Got a label that isn't in our common list? Drop it in (e.g. www, shop). Separate multiple labels with commas.

Frequently Asked Questions

Common questions about CNAME records and the failure modes this checker flags.

Not literally, no. RFC 1034 §3.6.2 says a name with a CNAME can't carry any other record type, and the apex is forced to carry SOA and NS. The two collide. Most authoritative nameservers will reject the configuration outright; the ones that don't will return inconsistent answers depending on the query type, which is worse.

What you actually want is ALIAS / ANAME (Route 53, DNSimple, Hetzner, others) or CNAME flattening (Cloudflare). Both look like "CNAME at the apex" in the control panel but return synthesised A and AAAA records to resolvers. The standard is satisfied and your MX, SPF and DMARC records keep working.

DNS doesn't let outsiders enumerate a zone. Zone transfers are locked down on any nameserver run by someone who's paying attention, and there's no other "list everything" query. The only thing a resolver answers is "does this exact name exist?"

So the tool asks that question for the sub-hosts vendors most commonly claim — www, autodiscover, shop, status, and a long tail. If you have a custom label that isn't in the set, paste it into the custom-host box and we'll fetch it directly.

The visible half is the broken link. old-marketing.example.com points at some-app.herokuapp.com, the Heroku app was shut down years ago, and visitors hit a hard failure.

The dangerous half is that several hosting platforms — S3, Heroku, GitHub Pages, Statuspage, Netlify, Vercel, Shopify, Fastly — hand any released hostname to the next person who asks for it. The CNAME still says "trust whatever is at that target." If an attacker claims the dangling name, they get to serve content on your subdomain, with a valid certificate, under your brand. This is the subdomain-takeover class of bug, and it's a regular bug-bounty payout for a reason.

The fix is to repoint the record at a live target or delete it. The checker flags these as errors when the target sits on a known takeover-prone suffix, and as warnings otherwise.

Two hops is normal. Three is fine. Four or more is worth a look.

Every extra hop is another resolver round-trip on a cache miss, and resolvers won't follow a chain forever — BIND defaults to 16, Unbound to 11, public resolvers tend to cap lower. The chain failing silently halfway through is the failure mode this flags: visitors get intermittent timeouts that don't show up in your synthetic monitoring because your monitoring is hot-cached. Collapse the chain at the source where you can.

How this CNAME checker works

A CNAME (RFC 1034 §3.6.2) is the alias record. It says "this hostname is really another hostname, go ask for that one instead." It's how you point shop.example.com at a Shopify storefront without hard-coding their IPs, or hand help.example.com to Zendesk.

Type a domain above and the tool probes a curated set of sub-hosts that vendors typically claim (www, autodiscover, cdn, status, help, shop, and a long tail of others). For each alias we find, we follow the chain to its final target, recognise the vendor where we can (Microsoft 365, Cloudflare, Shopify, Zendesk, SendGrid, GitHub Pages, Statuspage, and dozens more), and flag any target that fails to resolve. Lookups go over DNS-over-HTTPS with resolver fallback.

Why can't we list every CNAME in your zone?

DNS doesn't expose a "list everything in this zone" query to the public. Zone transfers (AXFR) are locked down on any sensible nameserver. The only thing a resolver will answer is "does this specific name exist?" — so the tool asks that question for the labels most likely to be in use. If you know a custom label that isn't in the curated set, paste it into the box at the bottom and we'll fetch it directly.

Why does a CNAME at the apex break things?

RFC 1034 §3.6.2 has one hard rule about CNAMEs: a name that has a CNAME can't have any other record type. That's fine at www.example.com, but the apex of your zone is forced to carry SOA and NS records — that's how the zone exists at all. Publishing a CNAME at example.com itself shadows those records, and resolvers behave in increasingly strange ways: 

example.com.    IN  CNAME  shop.shopify.com.   ← invalid
example.com.    IN  MX     10 mail.example.com. ← shadowed, may disappear

Our take: if your DNS host accepts a CNAME at the apex, it isn't honouring the RFC — it's doing CNAME flattening (Cloudflare's term) or publishing an ALIAS / ANAME record (Route 53, DNSimple, others) and synthesising A/AAAA answers at query time. That's the right pattern. A literal CNAME at the apex is the wrong one, and the checker treats it as an error.

What's a dangling CNAME, and why is it a security problem?

A dangling CNAME points at a target that doesn't resolve any more — a Heroku app you shut down, an S3 bucket you deleted, a Statuspage tenant that lapsed. The broken link is the boring half of the problem. The interesting half is that several hosting platforms hand any free hostname to whoever asks for it next. If old-marketing.example.com still points at some-bucket.s3.amazonaws.com and you've released that bucket, the next person to register it gets to serve content on your subdomain.

What to do: if a host shows up flagged here, either repoint it to a live target or delete the record. Subdomain takeover is the kind of finding that wins bug bounties because it's almost never noticed by the team that left the record behind.

How long should a CNAME chain be?

Two hops is normal (your name → the vendor → an A record). Three is fine. Beyond that, each hop is another resolver round-trip on the cold path, and resolvers will stop following the chain at some point — RFC 1034 doesn't set a hard ceiling, but BIND defaults to 16 and most public resolvers cap well below that. The tool flags any chain over three hops so you can collapse the indirection before it bites.

Where to go next

Some providers publish DKIM keys as CNAME delegations under selector._domainkey. There are too many of those to enumerate in this scan, so the DKIM checker handles them — it resolves the selectors, follows their CNAME chains, and validates the keys at the end. For the rest of your records, the TXT checker and DMARC checker cover the authentication stack.