Free CNAME Lookup & Generator

The apex problem, and which providers actually solve it

A CNAME record says "this name is an alias for that name". RFC 1034 requires that a name with a CNAME have no other records, and the apex of a zone always carries SOA and NS records. So a CNAME on example.com is invalid by construction, which is why www.example.com works and the bare domain does not.

Every DNS provider has a workaround and they are not equivalent:

The Route 53 row is the one that costs people an afternoon. Its Alias record looks like the answer, and it is genuinely good, but its targets are restricted to AWS resources (CloudFront, ELB, S3 website endpoints, API Gateway) and other records in the same hosted zone. Pointing an apex at a SaaS platform's hostname is not one of the supported cases. If you are on Route 53 and need the apex, your options are moving DNS to a flattening provider or hardcoding A records and accepting that they will eventually change under you.

CNAME flattening works by resolving the target at query time and answering with A records instead, so the client never sees a CNAME. That is why it is legal at the apex while a literal CNAME is not.

A correct CNAME does not mean a working site

DNS is one of three layers, and each fails differently. When a hostname is pointed correctly and still does not load, this is the order to check:

The most common of the three is the middle one, and it is the one people misread as a DNS problem. The CNAME resolving is necessary but it is not sufficient: the platform at the other end has to have been told your hostname exists. Many platforms only start certificate issuance once they see the CNAME resolve, so the sequence is CNAME first, then a wait measured in seconds to minutes, then HTTPS.

Chains, TTLs and the records that outlive their targets

Chains. A CNAME can point at another CNAME. Resolvers follow them, but every hop is another round trip on a cold cache, and providers cap the depth (commonly around ten) before returning SERVFAIL. Two hops is normal for SaaS custom domains, five is a smell.

TTLs. The TTL that governs a change is the one on the old record, since that is what resolvers cached. Lowering it to 300 the same time you make the change accomplishes nothing. Lower it at least one full old-TTL period ahead, make the change, then raise it back. 3600 is a sensible steady state.

Dangling records. A CNAME pointing at a platform resource you deleted is a dangling DNS record. Anyone who can claim that name on the provider then serves content on your hostname, which is subdomain takeover. When you offboard a customer or tear down an environment, delete the DNS record in the same change as the resource.

If you are the platform asking customers for a CNAME

Then this tool is a preview of your support burden. Every customer is on a different DNS provider, half of them will paste the full hostname into a field that wants only the subdomain label (producing app.example.com.example.com), some will have a proxy toggle on that breaks certificate validation, and a handful will be on a registrar whose DNS cannot do apex aliasing at all.

Domainee is a custom domains API for SaaS with a native MCP server, 50 domains and 100 GB free. It generates the per-customer record, watches DNS until it appears, handles certificate issuance and emits a webhook when the domain goes live. The Cloudflare SSL for SaaS guide walks through the DIY version if you would rather build it.

From the command line

Keyless, no signup:

curl -s "https://api.domainee.dev/v1/tools/cname-lookup?host=www.example.com" | jq

Rate limits are per IP and there is no uptime commitment, so it fits scripts and audits rather than a production dependency.