CNAME Lookup
CNAME Lookup helps you query canonical name (cname) alias records, for authoritative DNS validation, resolver checks, and faster troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
CNAME Lookup checks whether the hostname you enter is an alias and, if so, shows the canonical name it points to. It queries the CNAME record type for that exact label and reports the first target in the chain; when the name holds A or AAAA data directly, the result is informational rather than an error.
Why It Matters
- →Subdomain takeover risk: A CNAME left pointing at a deleted cloud bucket, app or CDN endpoint can be claimed by an attacker who then serves content on your subdomain.
- →SaaS onboarding: Help desks, status pages, landing-page builders and CDNs ask you to alias a subdomain to their hostname; this check proves the alias is live.
- →Apex limitations: Seeing no CNAME at example.com while www is an alias explains why the provider recommends ALIAS/ANAME or flattening at the root.
- →Mail safety: MX and NS targets must not be aliases, so finding a CNAME on a mail host name explains odd delivery failures.
- →Change tracking: Moving a subdomain between providers is often just a CNAME edit, and the lookup confirms resolvers now see the new target.
How to Read Results
- Status pass with 'is aliased to': The queried name is a CNAME; the message names the target the resolver received.
- canonical: The target hostname of the alias (the right-hand side of the CNAME). If that target is itself an alias, run the lookup again on it to walk the chain.
- allRecords: Every CNAME value returned. More than one value means the zone is broken, because a name may hold only one CNAME.
- Status info, no CNAME record found: The name answers with A/AAAA or other data directly, has no data at all, or does not exist. Apex domains always land here unless the provider is misconfigured.
- No IP addresses shown: This tool focuses on the alias itself; run an A or AAAA lookup on the canonical name to see where traffic ends up.
Technical Background
A CNAME (canonical name, type 5) record declares that one name is an alias for another. RFC 1034 section 3.6.2 sets the core rule: if a CNAME is present at a node, no other data should be present there, because the resolver restarts the query at the target and would otherwise have two conflicting sources of truth. RFC 2181 section 10.1 reinforces that a name can carry only one CNAME. DNSSEC records (RRSIG, NSEC) are the only permitted companions. In zone syntax an alias looks like shop.example.com. 300 IN CNAME stores.platform.example.net. and a resolver answering an A query for shop returns both the CNAME and the A records of the target in the same response.
The one-record rule is why a CNAME cannot be placed at a zone apex. The apex must hold SOA and NS records, so adding a CNAME there violates RFC 1034 and, in practice, many authoritative servers refuse to load the zone or behave unpredictably for MX and TXT queries. Providers solved the need to point a bare domain at a CDN with non-standard features: CNAME flattening, ALIAS or ANAME records. The authoritative server resolves the target itself and answers with synthesized A and AAAA records, so clients never see a CNAME. Flattened names will therefore show as having no CNAME in this tool, which is expected. The standards-track successor for this use case is the HTTPS/SVCB record (RFC 9460), whose AliasMode is allowed at the apex.
Aliases also constrain other record types. RFC 2181 section 10.3 says MX and NS targets must not be CNAMEs, and SRV targets are likewise required to be real hostnames by RFC 2782. Long chains cost extra lookups and each hop has its own TTL, so the effective cache lifetime is the shortest one along the chain. Resolvers also cap chain length to prevent loops.
The most serious operational risk is the dangling CNAME. When a team deletes a cloud resource such as a storage bucket, a PaaS app, or a CDN distribution, but forgets the DNS alias pointing at it, the target name may become claimable by anyone on that platform. An attacker who registers the same resource name then serves phishing pages or steals cookies scoped to your parent domain, and can often obtain a valid TLS certificate for your subdomain. Prevent this by removing DNS records before deprovisioning, inventorying every CNAME to third-party suffixes, and periodically checking that each target still resolves and returns content you own. An NXDOMAIN on the canonical name is a red flag that deserves immediate cleanup.
Common Errors and How to Fix Them
- ProblemProvider panel refuses to save a CNAME at @ (the root domain).
- FixUse the provider's ALIAS, ANAME or CNAME-flattening option, or publish the A/AAAA addresses the service documents. Keep the CNAME on www and redirect the apex to it.
- ProblemCNAME added next to existing TXT or MX records on the same subdomain.
- FixA CNAME must be alone at its name. Move the TXT verification or MX to a different label, or replace the CNAME with the target's A/AAAA records if both are required.
- ProblemThe canonical target returns NXDOMAIN after a SaaS or cloud resource was deleted.
- FixDelete the CNAME immediately to close the subdomain takeover window, then review other records that point to the same platform suffix.
- ProblemMX record points to a hostname that is a CNAME.
- FixPoint the MX at a name that has A/AAAA records directly, as required by RFC 2181. Many receivers tolerate the alias, but some reject or defer the mail.
- ProblemTarget entered without a trailing dot produced www.example.com.example.com.
- FixIn raw zone files, write fully qualified targets ending in a dot (target.example.net.). In web panels, enter only the hostname and check the preview.
Frequently Asked Questions
Can I use a CNAME on my root domain?
Not according to the DNS standards. The apex must hold SOA and NS records, and RFC 1034 forbids other data next to a CNAME. Use your DNS provider's ALIAS, ANAME or flattening feature, publish A and AAAA records directly, or rely on an HTTPS record in AliasMode where clients support it.
What is a dangling CNAME and how is it exploited?
It is an alias whose target resource no longer exists, for example a deleted cloud app or storage bucket. If the platform lets anyone create a resource with that same name, an attacker claims it and your subdomain starts serving their content, enabling phishing or cookie theft. Removing unused CNAMEs is the fix.
Should I use CNAME or A record for a subdomain?
Use a CNAME when a third party controls the destination and may change its IP addresses, such as a CDN or SaaS platform. Use A/AAAA when you control a fixed server address. A CNAME adds one resolution step but saves you from tracking someone else's IP changes.
Why does this tool say no CNAME when my provider shows one?
If your provider uses CNAME flattening, the authoritative servers answer with A and AAAA records instead of the CNAME you configured, so public DNS never exposes it. Proxied records on some CDNs behave the same way. It can also mean you queried the apex while the alias is on www.
How long does a CNAME change take to work?
Clients pick up the new target once the old CNAME expires from resolver caches, which depends on its previous TTL. Because the chain also involves the target's own TTL, lower the CNAME TTL to around 300 seconds a day before a planned migration to make the switch quick.
Academic Documentation
Protocol context and primary references
REST API Documentation
v1.0GET /api/tools/cname-lookup
curl -X POST https://epcybertools.com/api/tools/cname-lookup \
-H "Content-Type: application/json" \
-d '{"domain":"www.google.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Show only the alias target
dig CNAME www.example.com +short
# Follow the full chain down to the addresses
dig A www.example.com +noall +answer