Support Library
Wildcard DNS vs Explicit Records
Wildcard DNS records compared with explicit records: inventory, failure behavior, certificates and scope, and when each one is the right choice.
The short answer
A wildcard record (*.example.com) answers for names that do not exist in the zone; an explicit record answers for one name only. Explicit records are easier to audit and fail safely, because a name you never created returns NXDOMAIN. Wildcards save work when you genuinely need many names to reach the same place, such as per-customer subdomains on a platform you run.
Side by side
| Explicit records | Wildcard record | |
|---|---|---|
| Unknown or mistyped name | NXDOMAIN | Answered with the wildcard's data |
| Inventory | The zone lists every name in use | DNS no longer shows which names are real |
| Retiring a service | Delete its records | Every unused name may still point at the old target |
| Adding a name | A DNS change each time | No DNS change |
| TLS certificates | One name per entry, or a SAN list | Usually a wildcard certificate, which a CA cannot validate with an HTTP file check; ACME CAs such as Let's Encrypt require the DNS challenge |
| Scope | Exactly the name and type published | Only names that do not exist, only under the nearest existing parent, only the types it holds |
The last row is often misunderstood. A wildcard does not answer for every absent name or every absent type. A name that exists with other types gets NODATA, and an existing name or empty non-terminal stops the wildcard from matching below it. Wildcard DNS Risks walks through the rules from RFC 4592.
When a wildcard is the right choice
- A multi-tenant application you operate, where every customer gets customer.app.example.com and your own servers decide what each name serves.
- Preview or test environments that create and destroy host names faster than DNS changes can keep up.
- A catch-all that sends invented names to your own error page rather than letting them fail.
In each case the wildcard points at infrastructure you control, which rejects or handles unknown names itself. Placing it below a dedicated label, such as *.app.example.com rather than *.example.com, limits how much of the domain it covers.
When to avoid it
Avoid wildcards that point at a third-party platform which routes by host name and lets any customer claim a name, at a CDN or load balancer you might later release, or anywhere you rely on NXDOMAIN to notice mistakes. In those cases explicit records are safer even though they take more upkeep.
How DNS Panopticon helps
Domain Visualizer's Advanced scan checks for a first-level wildcard by looking up a random name, and reports one as a finding. Zone Analyzer shows wildcards and explicit records side by side when you load a zone export, which is the quickest way to see whether a wildcard is still needed.
Sources and further reading
- RFC 4592: The Role of Wildcards in the Domain Name System
- RFC 1034: Domain Names, Concepts and Facilities: section 4.3.3 on wildcards
- RFC 9499: DNS Terminology: closest encloser and empty non-terminals
- OWASP: Testing for Subdomain Takeover