Wildcard DNS record widens the attack surface

What it is

The zone contains a wildcard DNS record, so every unlisted subdomain resolves.

Why it matters

It answers for names you never created, which makes subdomain enumeration meaningless as a defence and can route traffic for a name you did not intend to serve. Certificate and cookie scoping problems tend to follow.

Check whether you have one

What a wildcard record hands an attacker

A *.example.com record makes every possible subdomain resolve — including ones that only ever appear in phishing emails. secure-login.example.com, billing-update.example.com: with a wildcard, those resolve to *your* infrastructure and serve *your* certificate, which makes a phishing link materially more convincing than a lookalike domain. A proxied wildcard also means requests for arbitrary hostnames reach your origin, where a framework that routes on the Host header may do things you never planned for, and it masks stale entries — a service you decommissioned keeps “existing” because the wildcard answers for it.

Fix it manually

Enumerate what actually receives traffic, create explicit records for those, and delete the wildcard:

The legitimate exception is customer subdomains — a SaaS serving <tenant>.example.com genuinely needs the wildcard. In that case keep it, but route it to a handler that 404s unknown tenants, and keep the product’s own services (api., admin., staging.) on explicit records so they do not share fate with the catch-all.

How lumioguard fixes it

The scan lists the zone’s records, flags wildcards, and cross-references the hostnames your repo and deployment config actually use. The fix arrives as a guide: the explicit records to create, and the wildcard delete once nothing depends on it.