CNAME Records Explained: Aliases, Limitations, and the Subdomain Takeover Risk

You connect your app to Vercel. They tell you to add a CNAME record pointing www.example.com at cname.vercel-dns.com. You add it, your site loads, and you move on.

That CNAME is now a permanent dependency. If the target ever becomes unclaimed, someone else can take it. Most teams don't find out until a security researcher emails them.

What a CNAME record actually is

A CNAME (Canonical Name) record is an alias. Instead of mapping a hostname directly to an IP address like an A record does, a CNAME maps a hostname to another hostname.

www.example.com.    CNAME    example.com.
shop.example.com.   CNAME    stores.shopify.com.
docs.example.com.   CNAME    myteam.gitbook.io.

When a resolver looks up www.example.com and finds a CNAME, it follows the alias and resolves whatever the target points to. The final answer is the IP address of the target hostname, not of your domain directly.

This indirection is the point. It means you can point your subdomain at a third-party service and let that service manage its own IP addresses. When Shopify moves to a different server, your DNS doesn't need to change.

CNAMEs can also chain: shop.example.com might point to stores.shopify.com, which itself resolves via another CNAME before reaching an IP. Resolvers follow the chain automatically, but the effective TTL is the shortest one along the chain, which can cause caching behavior that's hard to predict.

The CNAME restriction at the root domain

You cannot place a CNAME record at the root of your domain (example.com with no subdomain prefix). This is a hard rule in the DNS specification.

The reason is that a CNAME record, by definition, says "this hostname has no other records, look somewhere else entirely." But your root domain needs to have other records alongside it: MX records for email, TXT records for SPF and ownership verification, NS records for delegation. A CNAME at the root would conflict with all of them.

This is why services that want you to point your bare domain at them offer workarounds. Cloudflare's CNAME flattening resolves the CNAME chain at query time and returns the final IP address, making it behave like an A record from the outside. Some DNS providers call this ALIAS or ANAME records. They solve the same problem differently, but none of them are standard CNAMEs at the root.

If your DNS provider doesn't support flattening and you need your bare domain to point somewhere, the answer is an A record with the target's IP, not a CNAME. The trade-off is that if the service's IP changes, your A record silently breaks. This approach only works reliably when the target IP is stable, which CDNs and SaaS platforms often can't guarantee.

Where CNAMEs show up in practice

CDN onboarding. When you put Fastly, Akamai, or another CDN in front of a subdomain, they typically ask you to point it at a hostname they control. Your traffic hits their network first, gets processed, and is forwarded to your origin.

Custom domains for SaaS tools. Vercel, Netlify, Heroku, GitHub Pages, Webflow, Gitbook, Intercom, and dozens of others use CNAMEs for custom domains. You point your subdomain at their hostname; they serve your content from it.

Internal service routing. In larger infrastructure, CNAMEs are used to give stable names to services that might move between environments or regions. api.example.com pointing at a load balancer hostname means you can update the load balancer without touching the DNS record your clients use.

Email and authentication services. Some services use CNAMEs for DKIM key delegation, letting them manage the key rotation without requiring you to update your DNS every time.

The subdomain takeover risk

This is the part most CNAME documentation skips.

When you create a CNAME pointing docs.example.com at myteam.gitbook.io, you're making a claim: "the content at this address is hosted by that service, under my account." But the DNS record doesn't verify that claim. It just says "go look there."

If you later cancel your Gitbook account and forget to remove the CNAME, myteam.gitbook.io becomes unclaimed. Anyone can create a free Gitbook account and claim that subdomain. From that point, they control what loads at docs.example.com, under your domain, with your domain's authority in the browser.

This has happened repeatedly with real companies. Security researchers (and attackers) routinely scan for CNAMEs pointing at unclaimed targets on Heroku, GitHub Pages, Fastly, AWS Elastic Beanstalk, and many other platforms. Many providers give obvious signals when a subdomain is claimable, and the can-i-take-over-xyz project maintains a public list of which services are vulnerable and how to identify dangling CNAMEs for each.

The attack doesn't require any change to your DNS records. It exploits a CNAME that still exists and still resolves correctly, pointing at a service you no longer own. Beyond serving malicious content, an attacker who controls the subdomain can also pass a DNS-01 ACME challenge and obtain a valid TLS certificate for it, giving them HTTPS under your domain.

What to watch for:

• Subdomains pointing at services your team no longer uses
• CNAMEs for old Heroku apps, GitHub Pages sites, or staging environments that were deleted
• Records left behind after migrating from one platform to another

Periodically audit your CNAME records and verify that each target is an active service under your control. If a service is decommissioned, remove the CNAME before or at the same time you remove the service.

How to check your CNAME records

To look up a CNAME for a specific hostname:

dig CNAME www.example.com
dig CNAME docs.example.com

To follow the full resolution chain and see the final IP:

dig www.example.com

This returns the CNAME alongside the resolved A record, so you can see both the alias and where it ultimately points.

To check what multiple resolvers around the world currently see, dnschecker.org queries from multiple locations without installing anything.

When a CNAME change is and isn't an alert

A CNAME that changes means one of two things: a planned service migration, or something unexpected.

Planned migrations look like a subdomain moving from one platform to another: docs.example.com switching from Gitbook to Notion. These should match a deployment or infrastructure change your team made.

Unexpected CNAME changes are worth investigating immediately. A subdomain redirected to an unknown hostname could mean someone with access to your DNS has pointed it somewhere they control.

The subdomain takeover risk described above is the harder case: the CNAME doesn't change, but the thing it points at does. A change alert won't catch this directly. What it will catch is if someone removes the CNAME after a takeover is discovered, or if a new CNAME is added to a subdomain you weren't monitoring.

The best defense is monitoring all your CNAMEs for changes and keeping an up-to-date list of what each one is supposed to point at. An unexpected change to a CNAME pointing at a CDN or SaaS provider is worth treating as a priority alert. See what to do when DNS monitoring alerts you for a full walkthrough of how to evaluate a change once you receive one.

How DNS monitoring fits in

OneDollarDNS monitors CNAME records alongside every other record type and alerts you when a value changes. If a CNAME on a subdomain is modified without a corresponding deployment, you'll know within the hour.

For the subdomain takeover risk, monitoring gives you the coverage you need on the change side: if a CNAME is removed, added, or modified, you'll see it. The other half is keeping your CNAME targets actively maintained so there's nothing to take over in the first place.