Support Library

Wildcard DNS Risks

How wildcard DNS records really match, why the risk depends on what they point at, how to test for one, and how to use them safely.

Author
CategoryDNS Failure Modes & Misconfigurations
Length4 minute read
UpdatedOctober 24, 2026

The short answer

A wildcard record such as *.example.com answers for names in your zone that do not otherwise exist. It is convenient, but it changes how mistakes and abuse look: typos, retired hostnames and invented names all resolve, so monitoring that relies on NXDOMAIN goes quiet, and anything an attacker can get your web server or hosting platform to serve under a made-up name will look like part of your domain.

The wildcard alone does not let anyone host content. The risk comes from what the wildcard points at.

What a wildcard actually matches

Wildcard matching, clarified in RFC 4592, is narrower than "every subdomain":

  • It only applies to names that do not exist in the zone. If mail.example.com exists with an MX record only, a query for its A record gets NODATA, not the wildcard's address.
  • It does not match the zone apex. *.example.com says nothing about example.com itself.
  • It can match more than one label. With no other records under it, a.b.example.com is answered by *.example.com.
  • An existing name blocks it below that name. If b.example.com exists, or is an empty non-terminal because x.b.example.com exists, then a.b.example.com is not matched by *.example.com and gets NXDOMAIN.
  • It only answers for the types it holds. A wildcard A record does not create MX or TXT answers.

The rule a resolver applies is to find the closest encloser, the longest existing ancestor of the queried name, and use a wildcard directly under it if there is one.

Where the risk comes from

Wildcard points toRisk
Your own web server, which serves one site whatever the host nameLow. Invented names show your normal site. Search engines may index duplicate hostnames.
A shared hosting or SaaS platform that routes by host nameHigh if the platform lets any customer claim an unclaimed host name: an attacker can attach login.example.com to their own account and serve a page under your domain. This is the wildcard form of subdomain takeover.
A retired service or released IP addressHigh. Every unused name now points at something you no longer control.
A wildcard MX or TXT recordMail routing and SPF answers for names you never planned, which can confuse receivers and reports

Wildcards also hide inventory. Because every name answers, DNS can no longer tell you which hostnames are real, and certificate monitoring becomes the better record of what is in use.

Testing for a wildcard

Ask for a random name that cannot exist. Use several, since a single test can hit a real record by chance:

$ dig +short A zq7-not-a-real-host.example.com

$ dig +short A zq7.zq8.example.com

An address in reply means a wildcard covers that level. NXDOMAIN with an empty answer means none does.

Reducing the risk

  • Prefer explicit records, and keep wildcards for cases that need them, such as per-customer subdomains on your own platform.
  • Point a wildcard only at infrastructure you control, which answers unknown host names with an error or your own default site.
  • If the target platform routes by host name, make sure only your account can claim names under your domain, for example with the platform's domain verification.
  • Review wildcards whenever you retire a service, and remove them rather than leaving them pointing at old addresses.

How DNS Panopticon helps

Domain Visualizer's Advanced scan looks up an A record for a random name under the domain. If it gets an answer, it reports that a wildcard exists, as a medium security finding. That tells you a wildcard is present at the first level; it does not show what the target serves or whether a platform would let someone claim names, so follow it with the checks above. In a zone export, Zone Analyzer lets you filter hostnames on * to list every wildcard.

Sources and further reading