Wildcard DNS records let a single entry answer for every possible subdomain under a zone, which sounds efficient until an attacker realizes it also answers for names nobody ever intended to create. A wildcard record, written as *.example.com, tells resolvers to return the same IP address or CNAME target for any query that doesn’t already have an exact match – so anything.example.com, totallyrandom47.example.com, or admin-portal-v2.example.com all resolve without anyone ever creating those names on purpose.
The convenience is obvious. A hosting provider running thousands of customer sites on subdomains doesn’t want to add a DNS entry for every account – one wildcard covers all of them. A SaaS platform offering white-label subdomains does the same. But that convenience comes with a tradeoff most teams don’t think through until something breaks.
How wildcard DNS records actually work
When a resolver queries foo.example.com and no exact A, AAAA, or CNAME record exists for that exact label, the authoritative server checks for a wildcard record at *.example.com and returns it if present. This happens at the zone level, not per-subdomain, so the owner of the zone has no visibility into which random strings someone might type or scan for.
RFC 4592 defines the behavior precisely, and it’s narrower than most administrators assume. A wildcard only matches if there is no exact match for the queried name and no closer wildcard match at a more specific level. If someone later adds a specific record for staging.example.com, that record takes precedence over the wildcard – which is exactly the kind of interaction that produces confusing troubleshooting sessions at 2am when a record “should” be resolving one way but isn’t.
The security risk nobody flags until it’s exploited
The core problem is that a wildcard record makes every possible subdomain resolve to something – usually the same web server, load balancer, or CDN endpoint as the main domain. That has three concrete consequences.
First, TLS certificate scope gets murky fast. If the wildcard points to a server with a wildcard certificate covering *.example.com, an attacker who can get any request routed to that server (via a misconfigured reverse proxy, a shared hosting neighbor, or a Host header injection) can potentially serve content that browsers trust as coming from example.com, without ever registering a subdomain in DNS themselves.
Second, wildcard records defeat a lot of subdomain enumeration defenses while simultaneously creating a false sense of security. Teams sometimes assume that because there’s no explicit record for a guessed subdomain, it “doesn’t exist” and therefore can’t be attacked. With a wildcard in place, every guess resolves successfully, which either masks real infrastructure behind generic responses or – worse – silently proxies traffic to a shared backend that wasn’t built to segregate tenants properly.
Third, and this is the one that shows up in bug bounty reports constantly: if the wildcard target is a CNAME to a third-party platform (Heroku, GitHub Pages, an old Azure App Service instance), and that platform-side resource gets deleted or the account lapses, every single one of the infinite subdomains the wildcard covers becomes a potential takeover surface simultaneously. That’s structurally different from a normal dangling CNAME on one forgotten subdomain – see how dangling CNAME records create takeover risk for the single-record version of this problem. With a wildcard, the blast radius is the entire domain namespace at once.
A scenario that plays out more often than teams admit
A marketing team spins up a wildcard record pointing to a CDN distribution so that campaign microsites can go live under *.promo.example.com without filing a DNS ticket every time. Eighteen months later, that CDN distribution is decommissioned during a vendor consolidation, but nobody remembers the wildcard exists because it never shows up in a normal DNS record review – most admins scan for specific hostnames, not the wildcard entry itself.
A researcher running automated subdomain enumeration against example.com’s zone (or picking it up from Certificate Transparency logs, since a wildcard cert issuance gets logged just like any other) finds that literally any subdomain they try resolves to a dead CDN endpoint that’s now claimable. Depending on the CDN provider’s claim process, that can mean full content control over an unlimited number of subdomains under the parent domain, which is a much bigger prize than the single forgotten subdomain takeovers most monitoring setups are built to catch.
Common mistakes teams make with wildcard records
Treating the wildcard as a “set and forget” convenience is the first mistake – nobody re-evaluates whether the original reason for it still applies six months later. The second is issuing a wildcard TLS certificate for the same scope and assuming the private key is protected everywhere it’s deployed; a wildcard cert compromised on one server compromises trust for every subdomain. The third, and the most common in audits, is using a wildcard to “silence” DNS errors during development and forgetting to remove it before the zone goes to production, effectively disabling NXDOMAIN responses for an entire domain.
An experienced DNS administrator treats a wildcard record as a standing exception that needs its own line item in every quarterly review, not as background configuration. That means checking, on a fixed schedule, exactly what the wildcard target currently is, whether that target is still owned by the organization, and whether the business justification for having it at all is still valid. Tracking record types and their specific risk profiles is worth doing systematically – a full breakdown of DNS record types and their risks covers where wildcards fit relative to A, CNAME, and TXT records.
What to do instead, when possible
The myth worth busting here: wildcard DNS is not inherently insecure, and plenty of legitimate multi-tenant platforms rely on it correctly. The risk isn’t the wildcard mechanism itself – it’s an unmonitored wildcard pointing at infrastructure the domain owner no longer controls. Removing the wildcard target’s dependency on a third-party service that can be deleted independently of the DNS record (self-hosting the catch-all response, or using a platform where the DNS binding and the service instance are provisioned and torn down together) closes most of the exposure without giving up the convenience.
For organizations that can’t avoid wildcards – multi-tenant SaaS, page builders, agencies managing client subdomains – continuous monitoring of what the wildcard actually resolves to matters more than it does for ordinary records, precisely because one silent change affects the entire subdomain space at once rather than a single host. Patterns like this show up regularly in reviews of how attackers exploit misconfigured DNS records in the wild, and wildcard misconfigurations tend to produce disproportionately large incidents relative to the single record involved.
FAQ
Does a wildcard DNS record slow down resolution?
No. Wildcard lookups resolve at the same speed as any other DNS query – the authoritative server just returns the wildcard’s value instead of an NXDOMAIN response when no exact match exists. There’s no added latency from the wildcard mechanism itself.
Can I use a wildcard record for just some subdomains and not others?
Not selectively within a single wildcard – it applies to any unmatched name at that level. You can, however, add specific records for subdomains you want to route differently, since an exact match always overrides the wildcard for that one name.
Will a wildcard record hide subdomain takeover attempts from monitoring tools?
It can, if the tool only checks whether a name resolves rather than what it resolves to and whether that target is still valid. Effective monitoring needs to track the wildcard’s actual target over time, not just confirm that lookups succeed.
Wildcard records solve a real operational problem, but they turn a single DNS entry into an attack surface the size of the entire domain namespace. Reviewing what a wildcard currently points to – on a schedule, not just when something breaks – is the one habit that keeps the convenience from turning into the biggest single point of failure in a DNS zone.