Domains
What is a wildcard domain?
A wildcard domain is a DNS configuration that matches any subdomain under a root domain: routing requests for any subdomain label to the same destination. The asterisk symbol, *: serves as the wildcard character representing any possible subdomain label. A wildcard DNS entry for *.example.com matches anything.example.com, whatever.example.com, random-string.example.com, and any other single-level subdomain of example.com that does not have a more specific DNS record defined.
The wildcard operates as a catch-all for subdomains, it handles requests for any subdomain that does not have its own explicit DNS record. If www.example.com has an explicit CNAME record the wildcard does not apply to it, the specific record takes precedence. If api.example.com has its own A record the wildcard does not apply there either. The wildcard only catches subdomains that have no more specific matching record, functioning as the default for all otherwise-unhandled subdomain traffic.
Wildcard domains are used across a range of scenarios, from SaaS platforms where each customer gets their own subdomain to redirect management configurations that need to catch all possible subdomain variants of a domain to security configurations where wildcard SSL certificates cover all subdomains simultaneously. Understanding how wildcard DNS records work, what they can and cannot do, and how they interact with other DNS records clarifies when wildcard configurations are the right tool.
How wildcard DNS records work
A wildcard DNS record is a standard DNS record: A record, CNAME record, or other type, with an asterisk as the leftmost label in the record name.
Wildcard A record: *.example.com A 203.0.113.42: routes all unmatched subdomain requests to the IP address 203.0.113.42. Any request for anything.example.com that does not match a more specific record resolves to this IP address.
Wildcard CNAME record: *.example.com CNAME target.platform.com: routes all unmatched subdomain requests to the hostname target.platform.com through CNAME resolution. The CNAME follows the same resolution chain as any other CNAME, resolving target.platform.com to its current IP address and routing traffic there.
DNS record specificity and priority: wildcard records have lower priority than explicit records for the same subdomain. If www.example.com has an explicit A record pointing to 192.0.2.1 and *.example.com has a wildcard A record pointing to 203.0.113.42 a request for www.example.com resolves to 192.0.2.1: the explicit record wins. The wildcard only applies to subdomains that have no explicit matching record.
Single-level matching: standard wildcard DNS records match only a single subdomain level. *.example.com matches shop.example.com and blog.example.com but does not match sub.shop.example.com or deeper nesting. A request for deep.nested.example.com is not matched by *.example.com: it would require a separate wildcard *.nested.example.com or explicit records for the deeper subdomain.
Wildcard propagation: wildcard DNS records propagate through the DNS system the same way as any other record, subject to DNS TTL values and DNS propagation timelines. Adding a wildcard record to a zone makes it active after the TTL-governed propagation period.
Wildcard domains and SSL certificates
Wildcard SSL certificates are closely associated with wildcard DNS configurations, though the two concepts are technically separate and serve related but distinct purposes.
Wildcard SSL certificates: an SSL certificate issued for *.example.com covers all single-level subdomains, www.example.com, shop.example.com, api.example.com, and any other subdomain, with a single certificate. The wildcard notation in the certificate tells browsers to accept the certificate for any subdomain matching the pattern.
Wildcard SSL certificates are particularly valuable when wildcard DNS is used, when many subdomains resolve to the same infrastructure through a wildcard DNS record each of those subdomains needs SSL coverage for HTTPS connections. A wildcard SSL certificate provides that coverage for all subdomains with one certificate rather than requiring individual certificates for each.
Wildcard SSL certificate limitations: wildcard certificates cover only single-level subdomains matching the pattern. *.example.com covers shop.example.com but not app.shop.example.com. A deeper subdomain requires either an explicit certificate for that specific name or a wildcard at the appropriate level, *.shop.example.com.
Wildcard certificates also do not cover the root domain, example.com: itself. A certificate for *.example.com covers subdomains but not the apex. A multi-domain SAN certificate including both example.com and *.example.com covers both the root domain and all its subdomains.
DNS validation for wildcard certificates: certificate authorities that issue wildcard SSL certificates require DNS validation, adding a specific TXT record to prove control of the domain. HTTP-based validation, serving a specific file at the domain, does not work for wildcard certificates because the validation must prove control of the entire subdomain namespace, which requires DNS authority rather than just control of one specific server. DNS validation confirms control of the DNS zone itself, proving the requester can issue certificates for all subdomains.
Let’s Encrypt wildcard certificates: Let’s Encrypt issues wildcard certificates through its ACMEv2 protocol using DNS-01 validation. Automated certificate management clients, Certbot, acme.sh, and others, can automate wildcard certificate issuance and renewal by automating the required DNS TXT record creation and removal. Redirect management platforms that provision SSL automatically handle wildcard certificate issuance for connected domains.
Wildcard domains in SaaS platforms
Wildcard DNS configurations are foundational to how many SaaS platforms provide per-customer subdomain functionality, giving each customer their own distinct web address under the platform’s root domain.
Per-customer subdomains: a SaaS platform at platform.com gives each customer their own subdomain, customer1.platform.com, customer2.platform.com, enterprise-client.platform.com. The platform cannot create explicit DNS records for each customer’s subdomain as new customers are added, the record creation would be manual and not scalable. A wildcard DNS record, *.platform.com CNAME app.platform.com: routes all subdomain requests to the platform’s application infrastructure regardless of which customer subdomain is requested.
Application-level routing: the application receives requests for any subdomain, customer1.platform.com, customer2.platform.com: and uses the subdomain label as a key to identify which customer account to serve content for. The Host header in the HTTP request contains the full requested domain name, the application reads it and looks up the corresponding customer account to serve the appropriate content.
Custom domain support: beyond platform subdomains many SaaS platforms allow customers to use their own domain names, shop.customer1.com rather than customer1.platform.com. This is implemented through CNAME records: the customer adds shop.customer1.com CNAME app.platform.com to their domain’s DNS. The platform receives requests for the custom domain and serves the appropriate customer content based on the Host header. Wildcard DNS at the platform level is separate from custom domain support, both may coexist.
Wildcard domains and redirect management
Wildcard DNS configurations interact with redirect management in several important ways, enabling powerful redirect patterns and enabling complete coverage of all subdomain variants.
Wildcard redirect source: a wildcard redirect rule matches any URL pattern, *.example.com or example.com/*: and forwards all matched requests to a destination. Combined with wildcard DNS that routes all subdomain traffic to redirect infrastructure a wildcard redirect rule can forward all subdomain traffic from a domain to a single destination.
This is useful for retired domains where content previously existed at many subdomains, blog.olddomain.com, shop.olddomain.com, support.olddomain.com: and all should be redirected to equivalent sections of the new domain. A single wildcard DNS record routes all old subdomain traffic to redirect infrastructure. A single wildcard redirect rule forwards all of it to the new domain.
Catching all subdomain variants: for domains used as redirect sources a wildcard DNS record ensures complete coverage, any subdomain variant of the old domain is caught and redirected rather than returning DNS errors. Even subdomains that were never officially used, help.olddomain.com, news.olddomain.com: are handled if someone follows an old link that used those addresses.
www and subdomain catch-all: a wildcard DNS record combined with explicit records for important subdomains creates a layered configuration. www.example.com has an explicit CNAME record. *.example.com has a wildcard record routing all other subdomains to redirect infrastructure. Important subdomains are handled specifically. Less important or unknown subdomains are caught by the wildcard and redirected appropriately.
HTTPS across all subdomains: a wildcard SSL certificate combined with wildcard DNS and redirect infrastructure ensures HTTPS works correctly for any subdomain that reaches the redirect infrastructure. Without a wildcard certificate HTTPS visitors to subdomains matched by the wildcard DNS record, but not specifically covered by explicit SSL certificates, receive certificate errors rather than redirect responses.
Wildcard domains and security
Wildcard DNS configurations introduce specific security considerations that targeted explicit DNS records do not.
Subdomain takeover via wildcard: if a wildcard DNS record points to infrastructure that is partially under third-party control, for example a wildcard CNAME pointing to a cloud platform where specific subdomains can be claimed, an attacker who claims an unclaimed subdomain on the cloud platform may be able to serve content under the wildcard domain. This is a variation of subdomain takeover that the wildcard configuration makes easier, the attacker does not need the domain owner to create a DNS record for a specific subdomain because the wildcard routes all subdomains to the target platform.
Exposure of all subdomains: a wildcard DNS record reveals that the organisation is using the wildcard pattern, this information is discoverable through DNS queries. More importantly it means any attempted subdomain, even invented ones, resolve to the wildcard destination rather than returning NXDOMAIN. This prevents subdomain enumeration through DNS non-existence responses, every subdomain appears to exist from a DNS perspective.
Wildcard certificate scope: wildcard SSL certificates covering all subdomains represent a significant cryptographic asset, a single certificate covering an unlimited number of subdomains. Compromise of the certificate’s private key, or the ability to issue the certificate through a compromised certificate authority, affects all subdomains simultaneously rather than just specific ones. Certificate security practices, secure key storage, regular rotation, CAA records limiting certificate issuance, are important for wildcard certificates.
CAA records and wildcards: CAA records that authorise wildcard certificate issuance require an explicit issuewild record, a standard issue record does not authorise wildcards. Organisations using wildcard SSL certificates must ensure their CAA records include both issue and issuewild entries for the authorised certificate authority:
Missing the issuewild record prevents wildcard certificate issuance even when the CA is listed in issue.
Checking wildcard DNS configurations
Wildcard DNS records can be verified through standard DNS query tools, though the wildcard pattern itself requires a specific query approach.
Querying for a specific wildcard match: to verify that a wildcard record is active and correctly configured query for a subdomain that should be matched by the wildcard but has no explicit record:
If the wildcard record is active this query returns the wildcard record’s value, the IP address or CNAME target. If no wildcard exists the query returns NXDOMAIN.
Querying the wildcard record directly: to query for the wildcard record itself specify it explicitly:
The backslash escapes the asterisk in the shell. This query asks specifically for the *.example.com record rather than performing a wildcard match.
Verifying specificity: to confirm that explicit records correctly override the wildcard query for both a subdomain with an explicit record and the same subdomain matched by the wildcard:
The two queries should return different values if the explicit record and wildcard record have different destinations, confirming that specificity is working correctly.
Common wildcard domain mistakes
No explicit records for important subdomains: relying entirely on the wildcard without creating explicit records for important subdomains that should be handled specifically. If www.example.com should point to different infrastructure than the wildcard destination an explicit record must be created, the wildcard’s catch-all behaviour will not distinguish it automatically.
Wildcard without SSL coverage: configuring a wildcard DNS record without corresponding wildcard SSL certificate coverage. HTTPS visitors to subdomains matched by the wildcard receive certificate errors rather than the expected content or redirect. A wildcard SSL certificate must be provisioned alongside wildcard DNS for HTTPS to work across all matched subdomains.
Wildcard creating redirect loops: a wildcard DNS record pointing to redirect infrastructure combined with a wildcard redirect rule whose destination is within the same wildcard scope creates a loop. Every request to a subdomain is redirected to a subdomain that is redirected again. Ensure wildcard redirect destinations are outside the scope of the wildcard DNS and redirect rule.
Forgetting about deeper subdomain levels: the standard wildcard matches only one subdomain level. Traffic to deep.nested.example.com is not matched by *.example.com and returns NXDOMAIN, potentially surprising for organisations that expected the wildcard to catch everything. Deeper levels require their own wildcard records or explicit records.