Wildcard Detection

A DNS wildcard like *.yourdomain.tld matches any subdomain that is not explicitly defined. RedScore detects them by asking for a random subdomain that should not exist; if it resolves, you have a wildcard. This is a warn, not a fail, because wildcards are sometimes intentional (multi-tenant SaaS, catch-all marketing). When they are not intentional, they expand attack surface: phishing kits can register your-domain-typo.yourdomain.tld and get a real answer, dropped subdomains can be silently taken over, and monitoring loses the ability to distinguish typos from real services.

Warn: a random subdomain resolved

The evidence shows the random label RedScore probed (something like rzqf2dy8mtkp7w.yourdomain.tld) and the A or CNAME answer that came back. Step one is deciding whether you intended this wildcard.

Scenario A: the wildcard is intentional (SaaS multi-tenancy)

Common when you serve customer.app.yourdomain.tld for many customers off the same cluster. Keep the wildcard, but harden it:

• Point the wildcard at infrastructure you control end-to-end. Avoid pointing it at a third-party CNAME (Heroku, Netlify, S3) you might lose control of, since that creates a wildcard subdomain takeover surface.
• Add explicit records for sensitive subdomains (admin, login, api, mail) so they never fall through to the wildcard target by accident.
• Do not wildcard MX. If you have *.yourdomain.tld MX set, every typo'd address routes to your mail server and gets relayed or bounced from your reputation.
• If you publish DKIM, SPF, or DMARC, scope them carefully. Wildcards plus TXT records get tangled fast.
• If you use DNSSEC, prefer NSEC3 with opt-out on wildcard-heavy zones to avoid leaking the rest of your namespace via NSEC walking.

Scenario B: the wildcard is unintentional

Either someone added it as a catch-all and never removed it, or your DNS provider added an implicit one for a preview/deploy feature you no longer use. Audit and remove.

• Check the zone file (or the DNS provider UI) for any record whose name is * or *.something.
• Check for shadow wildcards at sub-zones (*.api.yourdomain.tld, *.dev.yourdomain.tld). These are often forgotten.
• Check for wildcards published via a CDN or PaaS integration. Vercel, Heroku, Fly.io, Render, and others sometimes create wildcard CNAMEs for preview deployments. Disable preview-deploy domains if not in use.
• Before removing, list every subdomain that currently relies on the wildcard answering. Add explicit records for each one before pulling the wildcard, or services break silently.

Removing the wildcard

In a managed DNS UI (Cloudflare, Route 53, Google Cloud DNS, NS1, Azure DNS, DNSimple), delete the record whose name is *. In a BIND zone file, remove or comment out the line whose name is *. Reload the zone (rndc reload for BIND, save in the UI for managed providers) and re-probe.

Verify the fix

• Run dig +short A randomstring1234.yourdomain.tld @1.1.1.1. With the wildcard removed, the response should be empty.
• Repeat with CNAME: dig +short CNAME randomstring1234.yourdomain.tld @1.1.1.1.
• Try a few different random labels in case a previous response was cached.
• Re-run the RedScore lookup.

Common pitfalls

• Removing a wildcard without inventorying what it served. Real subdomains relying on the wildcard go dark immediately. Always enumerate first.
• Multiple wildcards at different depths. *.yourdomain.tld and *.app.yourdomain.tld are independent records; the more-specific one wins for matching subdomains under it. Both must be addressed if both exist.
• Confusing wildcard DNS records with wildcard TLS certificates. They are unrelated. A wildcard cert (*.yourdomain.tld) covers any hostname for TLS handshakes; it does not create or remove DNS entries.
• Wildcard CNAME pointing at an abandoned third-party service. This is the classic wildcard subdomain takeover: the third party releases the name, an attacker registers it on their account, and every wildcard-matching subdomain on your domain now resolves to attacker-controlled content.