CNAME Record Lookup & Chain Resolver
Inspect canonical name alias records, verify CDN/cloud routing targets (e.g. Cloudflare, AWS CloudFront, Shopify, Vercel), and diagnose DNS alias configurations.
Enter Subdomain
Type your subdomain (e.g. www.site.com, app.site.com).
Query DNS Over HTTPS
Our engine queries Cloudflare and Google DoH for canonical records.
Inspect Cloud Target
Verify target endpoint and verify correct cloud alias routing.
Confirms routing to AWS, Vercel, Shopify, and Cloudflare.
Helps prevent subdomain takeover vulnerabilities.
Shows exact caching duration in seconds.
- Never point a CNAME to another CNAME if avoidable; each redirect adds latency to DNS resolution.
- Audit decommissioned SaaS subdomains to ensure dangling CNAME records are removed promptly.
Frequently Asked Questions about CNAME Records
Helpful answers to common questions about checking username availability, domain extensions, and registration.
What is a CNAME record in DNS?
A CNAME (Canonical Name) record maps an alias hostname to another true canonical domain name. For example, 'www.example.com' can point to 'example.com' or a CDN hostname like 'cname.vercel-dns.com'.
Can I create a CNAME record for a root/apex domain (e.g. example.com)?
No, according to RFC 1034/1035, a CNAME record cannot coexist with other DNS records such as SOA or NS. Since the root domain requires SOA and NS records, standard CNAMEs cannot be set at the root level (though modern providers offer CNAME Flattening or ANAME/ALIAS records as a workaround).
What is a dangling CNAME record vulnerability?
A dangling CNAME occurs when a subdomain points to a third-party service (e.g., an S3 bucket or GitHub Pages) that has been deleted or unclaimed. Attackers can register the unclaimed endpoint to take over your subdomain.