Wildcard DNS Records: When the Asterisk Helps and When It Hurts

A wildcard DNS record is an entry whose name is a single asterisk, like *.example.com, and it answers queries for any subdomain that has no explicit record of its own. Ask for anything.example.com or login.example.com and, if no specific record exists for that exact name, the wildcard supplies the answer. It is a powerful shortcut for routing many subdomains to one place, but it comes with strict rules and some sharp edges: the asterisk must be the leftmost single label, a wildcard does not cover its own sub-subdomains, any explicit record always wins over it, and a careless wildcard can widen your exposure to abuse and subdomain takeover.

How a wildcard is matched

The matching rule is defined in RFC 1034 and refined by RFC 4592. A wildcard synthesizes an answer only when two conditions hold: there is no exact-match record for the queried name, and there is no more specific record between the wildcard and the query. Picture the asterisk as a stand-in for exactly one missing label.

; zone example.com
*.example.com.        IN  A   203.0.113.50
www.example.com.      IN  A   203.0.113.10

Given that zone, here is what resolves and what does not.

The asterisk must be leftmost and alone

The only valid wildcard form is a single asterisk as the first and only label of the name. These are the rules that trip people up.

• *.example.com is valid. sub.*.example.com and *sub.example.com are not treated as wildcards at all; the asterisk is read as a literal character.
• A wildcard matches exactly one label. *.example.com answers x.example.com but never x.y.example.com. To catch deeper names you would need an additional wildcard such as *.sub.example.com.
• The wildcard does not match the name it sits under. *.example.com does not answer example.com itself.

More specific records always override

Any explicit record, at any depth, shuts off the wildcard for that branch. This is the single most important behavior to internalize. If you publish www.example.com, the wildcard stops answering for www. Subtler: if you create a.b.example.com, then the mere existence of the b.example.com node means the wildcard no longer synthesizes answers for other names under b, which can surprise you with unexpected NXDOMAIN results.

Good use cases

Wildcards shine when a single application fields an open-ended set of subdomains and routes them itself.

1. Per-tenant SaaS subdomains. If every customer gets customer.app.example.com and your application layer decides what to serve based on the hostname, one *.app.example.com record points all of them at your ingress, and you never touch DNS when a new tenant signs up.
2. Catch-all testing and previews. Development and preview environments that spin up arbitrary hostnames can all land on one server with a single wildcard, saving you from creating a record per branch or per build.
3. Vanity or short-lived names that are created and discarded faster than you want to manage individual records.

The traps

The same breadth that makes wildcards convenient also makes them risky. Watch for these.

• It does not match its own subdomains. Teams assume a wildcard is recursive. It is not. *.example.com covers one level only, so multi-level hostnames silently fail unless you add wildcards at each level.
• Explicit records create blind spots. Adding a single deep record changes what the wildcard answers for siblings in that branch, producing NXDOMAIN where you expected the wildcard to cover.
• Wildcard MX invites abuse. A *.example.com MX record means every conceivable subdomain accepts mail, which spammers and backscatter abuse to harm your reputation. Publish MX only on the specific names that actually receive mail.
• Wildcards widen takeover risk. If a wildcard points at a cloud provider target (a load balancer, a platform hostname, an object store), then every unclaimed subdomain resolves to that target. If the underlying resource is ever deprovisioned but the wildcard stays, an attacker who can claim that target may serve content under any of your subdomains at once, not just one dangling name.
• They interact with DNSSEC and NSEC. In a signed zone, wildcards are handled specially: the server must prove with NSEC or NSEC3 records that no closer match exists before the synthesized answer is trusted. This is correct and automatic on good platforms, but it means wildcard responses carry extra proof records and are not a way to hide which names exist.

Wildcard versus an explicit record set

Use this quick decision guide before you reach for the asterisk.

A good rule of thumb: if you can enumerate the subdomains, create them explicitly. Reach for a wildcard only when the set is genuinely unbounded and your application, not DNS, is the thing deciding what each hostname does. When in doubt, start with explicit records and add a wildcard later only once the operational pain of managing them one by one is real and measurable, because it is far easier to add breadth than to claw it back once services depend on a catch-all answer.

Verify what your wildcard actually answers

Because a wildcard answers names you never explicitly created, test it with names that should and should not match, and confirm that your explicit records still override as intended.

$ dig random123.example.com A +short
203.0.113.50

$ dig www.example.com A +short
203.0.113.10

$ dig deep.sub.example.com A +short
; (empty: wildcard does not match two labels)

After publishing or changing a wildcard, check that the new behavior is live across resolvers with the Valla DNS propagation checker, and spot-check both a wildcard-matched name and an explicitly overridden name. For the related concepts, see the guides in the Valla DNS learning hub on DNS record types, subdomain takeover, and how caching and propagation affect new records.