CNAME Record Lookup

Find canonical name (alias) records which map one domain name to another.

About CNAME Records

A Canonical Name (CNAME) record is a type of DNS record that maps an alias name to a true or canonical domain name. CNAME records are typically used to map a subdomain such as www or mail to the domain hosting that subdomain's content.

Important Note: The DNS protocol does not allow you to attach a CNAME record to the root (apex) of a domain (e.g., example.com). They can only be used on subdomains (e.g., www.example.com).

Our CNAME Record Lookup follows the alias chain for any hostname, showing each canonical name in the chain and the address it finally resolves to. Use it to verify CDN and SaaS integrations, detect long alias chains that slow resolution, and spot dangling records that expose you to subdomain takeover.

What is a CNAME Record?

A CNAME (Canonical Name) record makes one hostname an alias for another. When a resolver encounters a CNAME, it stops looking at the original name and restarts its query against the target instead.

For example, if www.example.com has a CNAME pointing at example.com, every lookup for www.example.com is answered with whatever example.com resolves to. Change the A record on example.com and the alias follows automatically — that indirection is the whole point.

CNAMEs are how most SaaS integrations work. Your shop.example.com points at a hosted platform, your CDN endpoint points at the provider network, and your email marketing tracking domain points at the vendor. One rule matters above all: a name with a CNAME record cannot have any other record type alongside it.

Makes one hostname an alias for another hostname
Resolution restarts at the target, following the chain
Cannot coexist with any other record type at the same name
Not permitted at the zone root in standard DNS
The backbone of CDN and SaaS custom domain setups

Why CNAME Records Matter

CNAMEs create a dependency on infrastructure you do not own. That is usually convenient and occasionally dangerous: if the target is ever deprovisioned while your CNAME still points at it, an attacker can register that target themselves and serve content on your subdomain. This is subdomain takeover, and it is one of the most commonly exploited misconfigurations in bug bounty programmes.

Performance matters too. Every link in a CNAME chain is another round trip before the client gets an address, and chains of four or five hops are surprisingly common in accumulated legacy zones.

A CNAME pointing at a deprovisioned service enables subdomain takeover
Each additional alias hop adds latency to every first connection
A CNAME at the zone root breaks MX, NS and SOA records for the domain
Alias chains hide the true hosting provider from casual inspection
Abandoned CNAMEs accumulate silently and are rarely audited

How This CNAME Record Lookup Works

The tool queries DNS for the CNAME record type and follows each alias to the end of the chain.

Validates the hostname input against format and SSRF safety checks
Queries DNS for a CNAME record at the supplied name
Follows each alias target, recording every hop in the chain
Resolves the final canonical name to its A or AAAA address
Flags chains that fail to terminate at a resolvable address

How to Use the CNAME Record Lookup

Enter the hostname you want to check, such as www.example.com
Run the lookup to query live DNS
Review each hop in the alias chain that is returned
Confirm the final target is the provider you expect
If the chain does not resolve, the record is dangling and needs attention

Understanding Your CNAME Results

A CNAME lookup returns the alias chain and its final destination. Here is what each part means:

Field / Value	Meaning
`Canonical name`	The target the alias points at. Resolution continues from here. This is the hostname whose records actually answer the query.
`Chain length`	How many aliases were followed before reaching an address. One or two hops is normal. Four or more adds measurable latency and should be flattened.
`Final address`	The IP address the chain ultimately resolves to. If this is empty, the chain is broken and the hostname does not work.
`TTL`	How long resolvers cache the alias, in seconds. The effective cache lifetime of a chain is governed by the shortest TTL in it.
`NXDOMAIN target`	The alias points at a name that does not exist. This is a dangling CNAME — a subdomain takeover risk that should be removed immediately.

Common Problems & How to Fix Them

This is a dangling CNAME and a direct subdomain takeover risk. If the target is on a platform where anyone can claim an unused hostname, an attacker can serve their own content on your subdomain, harvest cookies scoped to your domain, and pass domain validation to issue certificates in your name.

Delete the CNAME record immediately. Then audit your whole zone for other aliases pointing at services you have stopped using.

Standard DNS forbids a CNAME at the root because the root must hold SOA and NS records, and a CNAME cannot coexist with other record types. Publishing one breaks MX records and therefore all inbound email.

Use your provider ALIAS, ANAME or CNAME flattening feature instead — these return the resolved address directly while keeping the other root records intact.

A name with a CNAME may hold no other record type. When a TXT or MX record sits alongside it, resolver behaviour becomes undefined and different providers return different answers.

Remove either the CNAME or the conflicting records. If you need a TXT record on that exact hostname, the name cannot be a CNAME alias.

Each hop is an extra DNS round trip before the browser can open a connection. Chains often grow when one vendor is layered on another over the years.

Point the record at the final canonical name directly where your provider permits it, removing the intermediate hops.

Best Practices

Audit CNAME records regularly and delete any whose target no longer exists
Never publish a CNAME at the zone root — use ALIAS or CNAME flattening instead
Keep alias chains to one or two hops to minimise resolution latency
Remove the DNS record before decommissioning the service it points at, not after
Document which vendor each CNAME belongs to so ownership is clear
Use a descriptive subdomain name that makes the integration obvious
Lower the TTL before migrating a CNAME to a new provider

Security Recommendations

Treat every dangling CNAME as an active vulnerability — subdomain takeover leads to cookie theft, phishing on your own domain, and fraudulent certificate issuance
Always remove the DNS record first when decommissioning a hosted service
Scan your full subdomain inventory for dangling aliases on a schedule, not just after incidents
Be aware that a subdomain under your control can pass domain-validated certificate issuance, so takeover means an attacker can get a valid certificate for your name
Restrict which subdomains carry authentication cookies so a takeover of one cannot compromise your main application
Pair regular CNAME audits with CAA records limiting which certificate authorities may issue for your domain

Frequently Asked Questions

A CNAME record makes one hostname an alias for another. When a resolver sees a CNAME, it abandons the original name and restarts the query against the target. It is the standard way to point a custom domain at a CDN or SaaS platform.

An A record maps a hostname directly to an IP address. A CNAME maps a hostname to another hostname, and resolution continues from there. Use an A record when you control the IP address, and a CNAME when a provider manages the address and may change it.

The zone root must hold SOA and NS records, and a CNAME cannot coexist with any other record type at the same name. Publishing one at the root breaks MX records and therefore all email. Use your DNS provider ALIAS, ANAME or CNAME flattening feature instead.

A dangling CNAME points at a target that no longer exists — typically a hosted service that was shut down while the DNS record stayed behind. On many platforms an attacker can claim that unused target and serve content on your subdomain. This is called subdomain takeover.

Each hop in an alias chain adds a DNS round trip before the first connection can open. One or two hops is negligible; four or five is measurable, particularly on high-latency mobile connections. Keep chains short.

Yes, and resolvers will follow the chain. It is permitted but discouraged beyond a couple of hops because of the added latency, and because a break anywhere in the chain takes the whole hostname down.

No. A name with a CNAME record may not hold any other record type. Doing so produces undefined behaviour that varies between DNS providers and resolvers. If you need a TXT record at that exact hostname, it cannot be a CNAME alias.