Wildcard DNS and Managing Subdomains at Scale

One `*.example.com` record catches every undefined subdomain—just mind the three catches: exact records win, wildcard certs cover one level, and naming discipline keeps it auditable.

When your product needs hundreds or thousands of subdomains—say, a SaaS handing every tenant its own tenant-a.example.com, tenant-b.example.com—adding DNS records one at a time is slow and error-prone. Wildcard DNS and bulk management exist for exactly this shape of problem.

What a wildcard record does

A wildcard is a record whose leftmost label is an asterisk:

*.example.com.  IN  A      203.0.113.10
*.example.com.  IN  CNAME  edge.example.com.

It means: any subdomain you haven't explicitly defined matches this record. a.example.com, x.y.example.com, even a made-up foobar.example.com all resolve to the same target. That's what lets you sign up a tenant and hand them a working hostname instantly, with no DNS change per tenant.

Match precedence: exact records win

This is the part people most often get wrong. An explicit record always beats the wildcard. Given:

  • a defined mail.example.com → 198.51.100.5, and
  • a .example.com → 203.0.113.10

mail.example.com resolves to 198.51.100.5; only the other, undefined subdomains fall through to the wildcard. Also note that typically matches a single label, and support for multi-level forms like ..example.com varies between resolvers—don't rely on it.

Risks and trade-offs

A wildcard is convenient precisely because it says "yes" to everything, and that cuts both ways:

  • Misdirected traffic and phishing surface. Any spelling resolves, so an attacker can stand up login.example.com for phishing, and genuine front-end typos that should 404 quietly "work" instead.
  • Certificates. To serve HTTPS on wildcard-generated hosts you need a wildcard certificate (.example.com). It covers one label only—a.b.example.com is not included—and issuance requires DNS-01 validation.
  • Weak auditability. With no per-host records, you can't enumerate the subdomains actually in use straight from DNS, which skews monitoring and asset inventory.

Managing many subdomains cleanly

Even with a wildcard in place, discipline still pays off:

  • A naming convention. Agree on a shape like <tenant>.app.example.com or api-<env>.example.com. It prevents collisions and makes records easy to match and reap with a pattern.
  • Bulk changes via API or IaC. Drive create/update/delete through your DNS provider's API—or manage records as code—so changes are reproducible and reversible, far safer than clicking through a console.
  • A wildcard cert with automated renewal. Issue and renew .example.com via ACME/DNS-01 instead of requesting a cert per host.
  • Pin critical hosts explicitly. Define www, mail, api and the like as exact records rather than leaving them to the wildcard, so their targets never drift.

When to use it—and when not to

A good fit: a large, dynamically growing set of tenants whose subdomains are homogeneous (all pointing at the same ingress layer) and need to work the moment they're created.

A poor fit: subdomains that route to different backends, anything needing fine-grained access control or an audit trail, or security-sensitive boundaries. There, define records explicitly—or script real records on demand.

Summary

A wildcard lets a single record absorb every undefined subdomain, which is a genuine win for multi-tenant SaaS—but keep three limits in view: exact records outrank the wildcard, HTTPS needs a wildcard certificate that covers only one level, and wildcards amplify misdirected traffic while eroding auditability. Manage the rest with a naming convention, bulk API/IaC changes, and explicit records for the hosts that matter. Reach for a wildcard when subdomains are homogeneous and growing; define them one by one when they're heterogeneous or need tight control.