Is a wildcard CNAME record valid?

Wildcard CNAME records are valid, but existing DNS names, closest-encloser rules, and delegation boundaries determine when they answer.

Guance Editorial Team 2026-10-27 3 min read Updated 2026-10-27

Best practices

Yes. A wildcard CNAME is valid DNS. It can provide an alias for names that do not exist in the relevant part of the zone. It is not a simple rule that matches every unspecified hostname at every depth.

*.example.com.  300  IN CNAME  sites.example.net.

With no intervening existing names or delegation, this can supply answers for names such as a.example.com and blog.example.com. A hosting service can use that pattern for tenant subdomains without creating each record separately.

Existing names change the result

An existing blog.example.com name prevents the wildcard from supplying answers at that name, even if the requested record type is absent. For example, a TXT-only blog.example.com does not fall back to the wildcard for an A query.

DNS wildcard synthesis uses the closest existing ancestor, called the closest encloser. If b.example.com does not exist, *.example.com can potentially synthesize an answer for a.b.example.com. If b.example.com exists, including as an empty nonterminal because it has descendants, the relevant wildcard becomes *.b.example.com. The resolver does not keep searching higher wildcards when that one is absent.

A delegation is another boundary. The child zone's authoritative servers determine answers within the delegated namespace.

Ordinary CNAME restrictions still apply

The wildcard owner *.example.com cannot hold both a CNAME and ordinary data such as A or TXT records. DNSSEC-related exceptions do not change that rule. Records at different owner names can coexist with the wildcard normally.

The wildcard does not cover the zone apex, example.com. A standard CNAME cannot be placed at that apex because the required SOA and NS records already exist there. Provider-specific alias flattening is a different mechanism.

Choose CNAME or address records

Wildcard record	Destination	Operational effect
CNAME	Another hostname	Follows the target's DNS changes, subject to caching and the target's availability
A or AAAA	An IP address	Uses an address you must maintain when the service moves

Use the target documented by your hosting provider. A CNAME chain can resolve, but unnecessary hops add dependencies; network-query costs depend on cached and bundled answers.

DNS does not configure HTTPS or tenant access

The application or gateway must recognize permitted Host values and reject unknown tenants. Pointing an arbitrary name to a server does not authorize access to a tenant.

TLS certificates must separately cover the requested hostname. A typical *.example.com certificate matches one label, such as a.example.com, but not a.b.example.com or the apex. A wildcard certificate is convenient for some deployments, but individual certificates or suitable SAN certificates can also work.

Troubleshoot a missing answer

Check whether the exact name or an intervening ancestor already exists, whether a delegation changes the responsible zone, and what the authoritative server returns. Then inspect recursive and local caches, including cached negative answers. A local cache flush alone cannot refresh every upstream cache.

DNS control panels vary: some expect *, while others accept the complete name. Avoid accidentally creating *.example.com.example.com by supplying an absolute name where the provider appends the zone.