A wildcard record answers for any subdomain that has no record of its own. One entry, and every possible name under the domain resolves.
*.example.com. 3600 IN A 203.0.113.10
Now anything.example.com, customer42.example.com and typo.example.com all point at that address.
When it is the right tool
Applications that create a subdomain per customer. Without a wildcard, every new signup requires a DNS record, which means either an API integration with your DNS provider or a manual step in the middle of an automated flow.
A wildcard removes that entirely: the application decides which names are valid, and DNS simply answers.
Also useful for a development environment where branch or feature names become hostnames, and creating records for each would be constant work.
One level only
This is the limit that surprises people.
*.example.com matches shop.example.com. It does not match uk.shop.example.com, because that is two labels deep.
For that you need a second wildcard:
*.shop.example.com. IN A 203.0.113.10
The same restriction applies to wildcard certificates, and for the same reason, wildcard and multi-domain certificates walks through that side, and the two have to agree or the certificate will not cover the names the DNS answers for.
Explicit records win
Any subdomain with its own record uses that record and ignores the wildcard.
*.example.com. IN A 203.0.113.10 mail.example.com. IN A 198.51.100.5
mail goes to the second address; everything else falls through to the wildcard. That is how you keep the convenience while pointing specific names elsewhere.
The important corollary: adding a specific record removes that name from the wildcard entirely, including for record types you did not specify. A subdomain given an A record no longer inherits the wildcard's TXT or MX records, which is a genuinely confusing failure when a verification record stops being found.
The cost: your typos now work
Without a wildcard, shpo.example.com fails to resolve and the mistake is immediately obvious.
With one, it resolves, connects, and serves whatever that address serves. The visitor gets the wrong site, a certificate warning, or a confusing default page: none of which says "that hostname does not exist".
Monitoring that checks whether a name resolves also stops being useful, because every name resolves. Checks must test the actual response instead.
Mail is worth thinking about
A wildcard MX record makes every possible subdomain accept mail, which is almost never intended and produces spam directed at invented addresses.
If you need a wildcard for the web, keep mail explicit. And if the domain does not receive mail at those names at all, say so:
*.example.com. IN MX 0 .
Parking or holding a domain explains the same records used deliberately.
Certificates need to keep up
A wildcard in DNS without a wildcard certificate means every new subdomain resolves and then shows a browser warning.
Either obtain a wildcard certificate, which requires DNS-based validation and therefore some automation, or accept that certificates must be issued per name, which partly defeats the point.
Deciding this before deploying the wildcard avoids the situation where the application creates customer subdomains faster than certificates appear. Managing AutoSSL walks through the automatic issuance side.
Checking what is happening
dig random-name-nobody-would-use.example.com +short dig shop.example.com +short
The first query is the test: if a name nobody has ever created returns an address, a wildcard is in effect, which is worth knowing when diagnosing a domain you inherited.
Using dig and nslookup walks through reading the answers, and which record type you need deals with the alternatives.
Every name resolving is itself a risk
A wildcard means no subdomain ever fails to resolve, and that removes the signal that something is wrong.
The specific danger is a name that used to point at a service you no longer run. Without a wildcard it stops resolving and the link breaks visibly. With one it resolves to your server, and whatever answers there is served under your domain.
dig anything-at-all.example.com +short dig old-service.example.com +short
If both answer with the same address, every historical subdomain in old links, old documents and old bookmarks now lands somewhere. Decide what that destination is rather than letting it be whatever the web server does by default.
What a wildcard does not match
Three exceptions catch people out, and each produces a name that behaves differently from every other.
The domain itself. A wildcard does not answer for example.com. That needs its own record.
Names with an explicit record. Any record of that type wins, which is the intended behaviour and also means a stale explicit record is invisible behind a working wildcard.
Delegated subzones. If a subdomain is delegated elsewhere with NS records, the wildcard never applies to anything under it.
dig example.com A +short dig www.example.com A +short dig sub.example.com NS +short
Check all three before assuming the wildcard covers everything. Using dig and nslookup goes into reading the answers.
Typos stop being detectable
Normally a mistyped hostname fails immediately and obviously. Behind a wildcard it resolves, connects, and produces whatever the default site is.
The practical result is that a configuration error in a script, a mail client or a monitoring check no longer announces itself. It quietly talks to the wrong place, and the failure surfaces later as data in the wrong site or a check that has been green while testing nothing.
Where a wildcard is genuinely needed, point its default destination at something that says plainly that the name is not configured, rather than at the main site. An obvious page costs nothing and turns a silent fault into a visible one.
The alternative worth considering
Most reasons for a wildcard are really a reason to create records automatically.
If subdomains are created by an application, that application can create the DNS record too, through the provider's API at the moment the subdomain is provisioned. The result is an explicit record per name, which can be listed, audited and removed.
A wildcard cannot be audited, because there is no list. That matters most when you want to answer a simple question later, which is what names exist and where each one points. Monitoring DNS and detecting unauthorised changes deals with keeping that record.