A wildcard record is not a vulnerability by itself, but it widens what your domain appears to serve. It answers for hostnames that do not exist, which can hide typos, make takeover audits harder and combine badly with wildcard certificates and cookies. Use one where a design needs it, and scope it narrowly.
What a wildcard does
A wildcard record has an asterisk as its leftmost label, for example the name *.example.com. RFC 4592 explains the mechanism: when a query names something that does not exist in the zone, the server may synthesise an answer from the wildcard. Names that do exist are not affected. A query for anything.example.com gets the wildcard's data even though no one created that host.
Typical uses are multi tenant software with a hostname per customer, preview environments, and catch all web servers.
Where the risk comes from
| Issue | Why it matters |
|---|---|
| Hidden typos | A mistyped internal hostname resolves instead of failing, so mistakes live longer |
| Audit blind spot | A zone list shows one wildcard but hides every name that resolves through it, so inventories are incomplete |
| Takeover surface | A wildcard CNAME pointing at a third party platform can expose every name under it if that platform lets others claim names |
| Phishing aid | Anyone can craft a long, convincing hostname on your domain that really resolves |
| Cookie scope | Parent scoped cookies reach every name the wildcard serves, see subdomain takeover impact |
| Certificate scope | A wildcard certificate plus a wildcard record means one key protects a large set of names |
The takeover point is worth care. MDN and Microsoft both describe subdomain takeover as a CNAME pointing at a service where nothing now answers. A wildcard CNAME can turn one stale target into many exposed names.
A scoping approach
- Ask whether you need it. Per tenant records created by your provisioning code give a precise inventory.
- Scope it down. Use a wildcard below a dedicated zone, for example under a customer content domain, rather than on the apex of your main domain.
- Keep it off your main registrable domain if the wildcard points to untrusted or customer controlled content.
- Validate hostnames in the application. Have the server reject Host headers it does not recognise, rather than serving a default site.
- Do not point it at third party platforms unless you know the platform's rules on who can claim names.
- Pair it with narrow cookies. Leave out the Domain attribute and use the host prefix.
- Document it. Record why it exists, who owns it and when it should be reviewed.
Wildcards and certificates
If you use a wildcard certificate, think about where the private key lives. A single compromise exposes every name. Compare with per host certificates in our wildcard certificate decision guide. Certificate Transparency logs, covered in using CT logs to find hostnames, show wildcard issuance but not the hostnames used under it.
Testing
Query a random name under the wildcard and see what answers. Request a name with a made up Host header against your web tier. If it returns a real application, tighten the default behaviour.
Safeguard's asset discovery and SBOM scanning cover software you run, and do not inspect DNS zones. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does a wildcard override a record I create explicitly?
No. An explicit record for a name takes precedence. The wildcard answers for names that do not otherwise exist in the zone.
Should I never use wildcards?
They have good uses, such as per customer hostnames. Keep them narrow, documented and reviewed.
Sources
- RFC 4592, The Role of Wildcards in the Domain Name System
- MDN, Subdomain takeover
- Microsoft Learn, Prevent dangling DNS entries and avoid subdomain takeover
Last reviewed: 19 October 2026.
