DomainsJuly 22, 20263 min read

Wildcard DNS and catch-all subdomains explained

One record to handle every subdomain? That's a wildcard. Here's how *.example.com works, when to use it, and the pitfalls to avoid.

NBy Nxeon

Adding a DNS record for every subdomain by hand is fine when you have three of them. When you have hundreds — or you don't know the names in advance — you need a wildcard. A wildcard record matches any subdomain that doesn't have its own record. Here's how it works and when to reach for it.

What a wildcard record is

A wildcard uses an asterisk (*) as the name, meaning "any subdomain not matched by a more specific record":

Type: A
Name: *
Value: 203.0.113.30
TTL: 3600

With this in place, anything.example.com, another.example.com and whatever.example.com all resolve to 203.0.113.30 — without you creating a record for each.

When wildcards shine

Wildcards are the right tool in a few clear cases:

Multi-tenant apps / SaaS. If every customer gets customer.example.com, a wildcard sends them all to your app server, which reads the hostname and serves the right tenant. No per-customer DNS edits.
Dynamic or user-generated subdomains. Blogs, stores or profiles that mint subdomains on the fly.
Dev and preview environments. *.dev.example.com pointing at a box that routes to whatever branch or preview matches.
Catch-all convenience. So a typo'd subdomain still lands somewhere sensible rather than failing.

Specific records always win

The key rule: a specific record overrides the wildcard. The wildcard only applies to names that have *no* record of their own. So you can mix them:

Type: A
Name: *
Value: 203.0.113.30      # catch-all app server

Type: A
Name: api
Value: 203.0.113.40      # api.example.com goes here instead

Here api.example.com resolves to .40 because it has its own record; every other subdomain falls through to the wildcard at .30.

The pitfalls to watch

Wildcards are powerful, which means they can surprise you:

They don't cover the apex. * matches subdomains, not example.com itself. You still need a separate A record for the root.
They don't nest automatically the way you might expect. A wildcard *.example.com matches foo.example.com but *not* foo.bar.example.com — deeper levels need their own wildcard (*.bar.example.com).
Catching everything can hide mistakes. With a catch-all, a mistyped or misconfigured subdomain still resolves, so problems can go unnoticed. Sometimes an explicit failure is more useful.
Wildcard MX or TXT can cause trouble. Be deliberate; a wildcard is usually meant for A/AAAA/CNAME, not mail or verification records.

Wildcard SSL certificates

If a wildcard sends many subdomains to one server, you'll want a certificate that covers them all. Let's Encrypt issues wildcard certificates for *.example.com, but they require a DNS challenge (adding a TXT record) rather than the simpler HTTP one:

sudo certbot certonly --manual --preferred-challenges dns \
  -d "*.example.com" -d example.com

Certbot gives you a TXT record to add; once it verifies, one certificate secures every subdomain the wildcard serves.

Verify it works

Test that arbitrary names resolve to the wildcard target:

dig random123.example.com +short
dig api.example.com +short

The first should return your wildcard IP; the second should return the specific record's IP, proving the override works.

The takeaway

Use a wildcard when subdomains are dynamic, numerous, or unknown ahead of time — SaaS tenants, user subdomains, preview environments. Remember specific records override it, the apex needs its own record, and pair it with a wildcard certificate for HTTPS. In Nxeon's DNS panel you can set a * record alongside your specific ones, so a multi-tenant app or a fleet of preview environments points where it should with a single line.

#dns#domains#wildcard#subdomains#advanced