Wildcard DNS Records: Use Cases and Pitfalls

Wildcard DNS Records: Use Cases and Pitfalls

A wildcard record (*.example.com) is a convenient way to handle an unlimited number of subdomains with one rule — but convenience hides sharp edges. Wildcards conflict with more specific records, complicate CAA and DNSSEC, and open new attack surfaces. This article covers use cases, RFC 4592 constraints, and best practices.

What a wildcard is

The asterisk in DNS means "any label here". The record:

*.example.com.  3600  IN  A  93.184.216.34

matches foo.example.com, bar.example.com, anything — as long as there is no specific record for that subdomain.

When wildcards are useful

• SaaS apps with dynamic tenant subdomains: client1.app.com, client2.app.com.
• Catch-all email: *.example.com MX so every subdomain accepts mail.
• Staging / preview environments: *.preview.example.com for CI PR deployments.
• DDoS protection: sinkholes for bot traffic.

RFC 4592 constraints

1. Wildcards don't span multiple levels

*.example.com does not match a.b.example.com. You need an explicit *.b.example.com.

2. Specific records override wildcards

Given shop.example.com A 10.0.0.1 and *.example.com A 10.0.0.2, a query for shop.example.com returns 10.0.0.1.

3. Wildcards don't cover apex

*.example.com does not match example.com. Apex needs its own record.

4. Empty non-terminal blocks wildcards

The trickiest trap. If you have *.example.com and a.b.example.com, a query for b.example.com will not return the wildcard — it returns NODATA or NXDOMAIN — because b.example.com becomes an empty non-terminal between apex and a.b.example.com.

5. Doesn't apply across types

A wildcard of one type (say MX) does not imply a wildcard for other types (A, TXT). Define each type separately.

Correct and incorrect examples

Correct

example.com.      A    10.0.0.1
*.example.com.    A    10.0.0.2
www.example.com.  A    10.0.0.3
api.example.com.  A    10.0.0.4

; dig foo.example.com +short, returns 10.0.0.2
; dig www.example.com +short, returns 10.0.0.3

With the pitfall

*.example.com.        A    10.0.0.2
a.b.example.com.      A    10.0.0.3

; dig b.example.com +short, returns NXDOMAIN (!)
; dig x.example.com +short, returns 10.0.0.2

Wildcards and TLS certificates

Let's Encrypt supports wildcard certs via DNS-01 challenge. A *.example.com cert covers all first-level subdomains but not nested ones.

certbot certonly --dns-cloudflare \
    -d example.com \
    -d *.example.com

Wildcards and CAA

CAA controls which CAs may issue certs. Wildcards have their own directive:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"

Wildcards and DNSSEC

DNSSEC signs RRsets — wildcards sign like any other record. Validation, however, adds NSEC/NSEC3 proofs that no more-specific record exists.

Security

Subdomain takeover

Wildcards pointing to a cloud service (e.g., AWS S3 bucket) create a takeover risk: an attacker registers a matching service and hijacks any subdomain.

DDoS vector

Wildcards accept any subdomain — bots can generate infinite random names to bypass filters. Mitigation: explicit records plus anomaly monitoring.

Phishing surface

Wildcards make it easy to create credible phishing URLs (amazon-login.example.com). Monitor subdomain usage.

Checking wildcards

With DNS Lookup or dig:

dig A random-subdomain.example.com +short
dig ANY example.com +noall +answer

Best practices

1. Use wildcards intentionally — not as a default.
2. For critical subdomains (www, mail, api) always define explicit records.
3. Document wildcard strategy in the zone (BIND comments).
4. Monitor subdomain request patterns via authoritative query logs.
5. Test empty non-terminal (ENT) behaviour when designing hierarchies.

FAQ

Can I wildcard a CNAME?

Yes: *.example.com CNAME myapp.vercel.app. Works, but watch for takeover.

How do I "disable" the wildcard for one subdomain?

Add a specific record for it — specifics override wildcards.

Does Cloudflare support wildcards?

Yes on all plans. The orange-cloud (proxy) on wildcards is Business+ only.

Does wildcard MX work?

Yes: *.example.com MX 10 mail.example.com — any subdomain routes there.

Conclusion

Wildcards are powerful but dangerous. Use them for genuinely dynamic SaaS scenarios and always supplement with explicit records for critical names. Verify via DNS Lookup, monitor via Enterno.io Monitors, and pair with CAA + DNSSEC to minimise risk.