CNAME Lookup

What a CNAME record does

A CNAME (canonical name) record says that one name is an alias for another. When a resolver asks for the address of www.example.com and finds a CNAME to app.example.net, it restarts the lookup for the target and returns the target's addresses. The alias therefore has no addresses of its own; whoever controls the target controls where the alias goes. This is why CNAMEs are the usual way to point a name at a hosting, CDN or SaaS provider that may change its addresses.

The tool follows the chain one hop at a time, asking for the CNAME at each name, until it reaches a name with no further alias or a stopping condition. It then checks the final name for A and AAAA records.

How to read the result

• Chain ends at a name with addresses: the alias resolves. The tool lists the chain, the target and the addresses found there.
• Loop detected: the chain returns to a name it already visited. Resolvers will fail on it, so this is reported as a high-severity risk.
• Chain longer than eight hops: the tool stops following and reports it as something to improve. Each hop is an extra lookup, and some resolvers give up on long chains. A chain of a few hops is informational.
• Dangling target (NXDOMAIN): the final name does not exist, so the alias leads nowhere. This is reported as a risk and is the pattern behind subdomain-takeover problems, because the abandoned target may be claimable by someone else.
• Target exists but has no address: the end of the chain has neither A nor AAAA, so clients cannot connect even though the name exists.
• CNAME at the zone apex: reported when the name is a delegation point. An apex always has SOA and NS records, and a CNAME cannot sit beside them.
• Lookup failure partway: a timeout or SERVFAIL at a hop means that the rest of the chain is unknown. The tool says the target is not concluded rather than guessing.

Rules that CNAMEs must follow

The standards (RFC 1034 and RFC 2181) say a name with a CNAME may hold no other record types, apart from DNSSEC records, which is why the apex is a special case. Records like MX, NS, SOA, TXT and SRV also expect canonical names, not aliases, as their targets. Many providers offer proprietary apex flattening, called ALIAS or ANAME, that synthesises address records at query time. The tool treats that as ordinary A and AAAA records, because that is what resolvers see.

Common CNAME problems

• Coexisting records: a CNAME added at a name that already has a TXT or MX record. Some providers reject this and others accept it and cause inconsistent answers.
• Decommissioned service: the SaaS account was closed but the CNAME stayed behind, leaving a dangling target.
• Target typed without a trailing dot: the panel appends your own zone, so the alias points at a name inside your zone that does not exist.
• Chain through several providers: each extra alias is another party that can change or expire.
• Alias of an alias that loops: often a result of two teams each adding a CNAME pointing at the other.

How to change CNAMEs safely

Record the existing alias target and TTL before changing anything. Check that the new target is already set up to serve your host name, since many providers refuse requests for names they do not know, which shows up as errors rather than as a DNS failure.

To delete a CNAME, remove the DNS record first and the service afterwards only if the host name is no longer needed anywhere; in the other order there is a window in which the name points at a service you gave up.

1. Save the current alias target and TTL.
2. Confirm the new target exists and is configured for the host name.
3. Replace the CNAME in one edit; do not add a second CNAME at the same name.
4. Re-run this lookup: the chain should end at a name with addresses.
5. Check the service itself over HTTPS from outside.
6. To roll back, restore the saved target; clients follow it as caches expire.

Limits of the test

This tool follows aliases in DNS only. It does not know whether the target service accepts your host name, whether a certificate covers the alias or whether a provider will let someone else claim an abandoned target. Results come from one scanner at one moment, using the system resolver and the zone's authoritative servers, and a recently changed CNAME may still be cached elsewhere for the length of its TTL.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09